[Bug target/24185] gcc.dg/vect/vect-shift-1.c execution test fails
--- Comment #3 from uros at kss-loka dot si 2005-10-09 08:04 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00414.html -- uros at kss-loka dot si changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24185
[Bug tree-optimization/24226] [4.1 Regression] ICE: Segmentation fault in operand_equal_p (complete loop unrolling)
--- Comment #7 from rakdver at gcc dot gnu dot org 2005-10-09 09:03 --- Testing a patch. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24226
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-09 09:47 ---
The non-null check is now removed for the foo_char() case by VRP (note that
the non-null check for the two viod-cases are _not_ removed by VRP but by DOM1.
The propagation of the initialization in foo_void_offset is layed ground
for by FRE, which changes
iftmp.3_6 = (struct Foo *) __p_5;
if (iftmp.3_6 != 0B) goto ; else goto ;
:;
this_11 = (struct Foo * const) iftmp.3_6;
this_11->i[0] = 1;
iftmp.3_12 = iftmp.3_6;
goto ();
:;
iftmp.3_10 = iftmp.3_6;
:;
D.2114_7 = (struct Foo *) &i[0];
D.2113_8 = D.2114_7->i[0];
return D.2113_8;
to
iftmp.3_6 = (struct Foo *) __p_5;
if (iftmp.3_6 != 0B) goto ; else goto ;
:;
this_11 = iftmp.3_6;
this_11->i[0] = 1;
iftmp.3_12 = iftmp.3_6;
goto ();
:;
iftmp.3_10 = iftmp.3_6;
:;
D.2114_7 = iftmp.3_6;
D.2113_8 = D.2114_7->i[0];
which can then be optimized further. This doesn't happen for the exact
same example with void * exchanged with char * -- is FRE paying attention
to some strict-aliasing rules here? Note there is no difference in alias
information after CCP1.
For the record, the char* example mentioned would look like
int foo_char(void)
{
int i[2];
new (reinterpret_cast(&i[0])) Foo();
return reinterpret_cast(&i[0])->i[0];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-10-09 09:56 ---
Another one is the following (without any possible aliasing problems):
int foo_charchar(void)
{
char i[2*sizeof(int)];
new (i) Foo();
return reinterpret_cast(&i[0])->i[0];
}
where we miss the FRE opportunity for the cast:
:
iftmp.0 = (struct Foo *) &i[0];
iftmp.0->i[0] = 1;
D.2097 = (struct Foo *) &i[0];
return D.2097->i[0];
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Missed constant propagation |Missed VRP and FRE
|with placement new |opportunities in the
||presence of casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-09 10:34 --- Subject: Bug 24061 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-09 10:34:47 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/tr1: hashtable unordered_map unordered_set Added files: libstdc++-v3/testsuite/tr1/6_containers/unordered/erase: 24061-map.cc 24061-multimap.cc 24061-multiset.cc 24061-set.cc libstdc++-v3/testsuite/tr1/6_containers/unordered/insert: 24061-map.cc 24061-multimap.cc 24061-multiset.cc 24061-set.cc Log message: 2005-10-09 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/24061 (issue 6.19) * include/tr1/hashtable (struct node_const_iterator, struct hashtable_const_iterator): New, add const variants to enable separate overloadings for iterator and const_iterator in unordered_set and unordered_multiset (as required by issue 6.19). (class hashtable): Change the mutable_iterators template parameter to constant_iterators and adjust throughout the logic. (hashtable::insert(iterator, const value_type&), erase(iterator) erase(iterator, iterator)): New, as per issue 6.19. (hashtable::m_erase(node*, node**)): New, called by erase(iterator) and erase(const_iterator). (hashtable::Insert_Conv_Type): New, used by insert(iterator, const value_type&) and insert(const_iterator, const value_type&) to delegate the work to insert(const value_type&). * include/tr1/unordered_map (class unordered_map, unordered_multimap): Adjust typedefs. * include/tr1/unordered_set (class unordered_set, unordered_multiset): Likewise. * testsuite/tr1/6_containers/unordered/erase/24061-map.cc: New. * testsuite/tr1/6_containers/unordered/erase/24061-multimap.cc: New. * testsuite/tr1/6_containers/unordered/erase/24061-multiset.cc: New. * testsuite/tr1/6_containers/unordered/erase/24061-set.cc: New. * testsuite/tr1/6_containers/unordered/insert/24061-map.cc: New. * testsuite/tr1/6_containers/unordered/insert/24061-multimap.cc: New. * testsuite/tr1/6_containers/unordered/insert/24061-multiset.cc: New. * testsuite/tr1/6_containers/unordered/insert/24061-set.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3126&r2=1.3127 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/hashtable.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/unordered_map.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/unordered_set.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-map.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-multimap.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-multiset.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-set.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-map.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-multimap.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-multiset.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-set.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Comment #8 from pcarlini at suse dot de 2005-10-09 10:36 --- Fixed for 4.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug middle-end/24282] Optimizer ignores register changing (STOSL)
--- Comment #2 from graeter at hydrixos dot org 2005-10-09 12:17 --- Subject: Re: Optimizer ignores register changing (STOSL) pinskia at gcc dot gnu dot org wrote: > --- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 03:11 > --- > In inline-asm if you say that you don't modify a register, you better not > modify a register. This is not a bug. But the modified register is a register of the input list, so gcc should know that it will be used. Or did I misunderstood this [1]: "5.3 Clobber list [..] We shoudnt list the input and output registers in this list. Because, gcc knows that "asm" uses them (because they are specified explicitly as constraints)." cu FG [1] (http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24282
[Bug middle-end/24282] Optimizer ignores register changing (STOSL)
--- Comment #3 from falk at debian dot org 2005-10-09 12:42 --- (In reply to comment #2) > But the modified register is a register of the input list, so gcc should > know that it will be used. It knows it is being read. It doesn't know that it is also clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24282
[Bug target/24284] New: [4.0 4.1 regression] ICE (Segmentation fault)
[forwarded from http://bugs.debian.org/329840]
works with 3.3.6, 3.4 CVS, fails with 4.0.2, CVS HEAD 20050904
When building zinc-compiler on sparc, I'm get:
run.nw: In function 'do_run':
run.nw:212: internal compiler error: Segmentation fault
It seems the following code is what is causing it:
void do_run(void *ip)
{
char dummy[8192];
__asm__("" : : "g"(dummy));
goto *ip;
}
A file with only that in will generate the ICE too.
It happens when using -O* and -g. -O0 or no -g makes it build.
Also, making the dummy buffer smaller than 8089 fixes it. 8089
still crashes, 8088 works without problems.
Compiling the same with gcc-3.3 or 3.4 works without problems.
--
Summary: [4.0 4.1 regression] ICE (Segmentation fault)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC host triplet: sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24284
[Bug fortran/24285] New: format( 1000(a,$))
[forwarded from http://bugs.debian.org/324600] Bug submitter writes: I had no compilation problems with g77. 300 format( 1000(a,$)) 1 Error: $ must the last specifier in format string at (1) 301 format(/1000(a,$)) Error: $ must the last specifier in format string at (1) If it is really a code problem what would be the correct syntax? Reply from FX Coudert: g77 documentation states: "A dollar sign at the end of an output format specification suppresses the newline at the end of the output." Since this (a $ as format specifier) is an extension, there is nothing in the standard against this. On the other hand, all the compilers I have at hand accept this, so I think we might as well remove this contraint. I think this can be reported as a bug. -- Summary: format( 1000(a,$)) Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285
[Bug target/24284] [4.0/4.1 regression] ICE (Segmentation fault)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 14:02 ---
Confirmed.
The backtrace:
#0 0x001bfaf0 in dwarf2out_frame_debug_expr (expr=0x0, label=0x55c1dc
"*.LLCFI0") at ../../gcc/dwarf2out.c:1461
#1 0x001c0de0 in dwarf2out_frame_debug (insn=0x0, after_p=1 '\001') at
../../gcc/dwarf2out.c:1849
#2 0x0022c3f4 in final_scan_insn (insn=0x41e12500, file=0xa36778d0,
optimize=2, prescan=0, nopeepholes=0, seen=0xb768) at
../../gcc/final.c:2542
#3 0x0022ad90 in final (first=0x41e0b220, file=0xa36778d0, optimize=2,
prescan=0) at ../../gcc/final.c:1577
#4 0x003ced88 in rest_of_handle_final () at ../../gcc/passes.c:300
#5 0x003d2304 in rest_of_compilation () at ../../gcc/passes.c:1756
#6 0x0009da64 in execute_one_pass (pass=0x547624) at
../../gcc/tree-optimize.c:533
#7 0x0009dbc8 in execute_pass_list (pass=0x547624) at
../../gcc/tree-optimize.c:570
#8 0x0009df88 in tree_rest_of_compilation (fndecl=0x41e708dc) at
../../gcc/tree-optimize.c:668
#9 0x0001d3d0 in c_expand_body (fndecl=0x41e708dc) at ../../gcc/c-decl.c:6608
#10 0x003f5dd0 in cgraph_expand_function (node=0x41e70d14) at
../../gcc/cgraphunit.c:835
#11 0x003f8598 in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1706
#12 0x003f89bc in cgraph_optimize () at ../../gcc/cgraphunit.c:1803
#13 0x000204dc in c_write_global_declarations () at ../../gcc/c-decl.c:7586
#14 0x0039ef68 in compile_file () at ../../gcc/toplev.c:1004
#15 0x003a1c58 in do_compile () at ../../gcc/toplev.c:2103
#16 0x003a1cf4 in toplev_main (argc=4, argv=0xbd64) at
../../gcc/toplev.c:2135
#17 0x0007ebf8 in main (argc=4, argv=0xbd64) at ../../gcc/main.c:35
The insn which we are getting an ICE for:
(insn/f 33 37 34 t.c:3 (set (reg/f:SI 14 %sp)
(plus:SI (reg/f:SI 14 %sp)
(reg:SI 1 %g1))) 127 {addsi3} (insn_list:REG_DEP_TRUE 32 (nil))
(expr_list:REG_DEAD (reg:SI 1 %g1)
(expr_list:REG_FRAME_RELATED_EXPR (nil)
(nil
We are looking at REG_FRAME_RELATED_EXPR but its expression is null.
The regnote is created around sparc.c:4603 (this is from the 4.0 branch.
Oh, the reason why smaller stacks fail is because the regnote is only created
for stack size greater than 8192.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|sparc-linux |
GCC target triplet||sparc-*
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-10-09 14:02:43
date||
Summary|[4.0 4.1 regression] ICE|[4.0/4.1 regression] ICE
|(Segmentation fault)|(Segmentation fault)
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24284
[Bug debug/24267] [3.4 only] Bad DWARF for altivec vectors
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 14:25 --- Fixed in 3.4.5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.6 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
[Bug tree-optimization/23968] [meta-bug] VRP bug reports
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 15:44 --- Closing as there is only one bug left. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23968
[Bug c++/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-09 15:44 --- I think this was decided that this was a front-end bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c++/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Comment #46 from pinskia at gcc dot gnu dot org 2005-10-09 15:45 --- The real fix is a front-end fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug fortran/24286] New: Unclassifiable statement when using pointer subroutine
When compiling this code, I get a compiler crash. I believe that it has to do with using a pointer in a subroutine. In file testtree.f90:34 addnode(head, thisnode, i) 1 Error: Unclassifiable statement at (1) testtree.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This occurs with Windows XP or cygwin with the GNU Fortran 95 (GCC 4.1.0 20050902 (experimental)) version of gfortran. -- Summary: Unclassifiable statement when using pointer subroutine Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denney at seas dot upenn dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
[Bug fortran/24286] Unclassifiable statement when using pointer subroutine
--- Comment #1 from denney at seas dot upenn dot edu 2005-10-09 16:32 --- Created an attachment (id=9945) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9945&action=view) Initial test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
[Bug fortran/24286] Unclassifiable statement when using pointer subroutine
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 16:36 --- addnode(head, thisnode, i) You want: call addnode(head, thisnode, i) With that change we get more errors about the same thing. Though I cannot reproduce your ICE though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
[Bug middle-end/20638] gcc doesn't take advantage of attribute malloc on alloca
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 16:54 --- Fixed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20638
[Bug fortran/24286] Unclassifiable statement when using pointer subroutine
--- Comment #3 from denney at seas dot upenn dot edu 2005-10-09 16:59 --- With this fixed code, the initial test case now compiles correctly in the windows version. (It segfaults on running, but that's my coding problem, not a compiler problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
[Bug fortran/24286] Unclassifiable statement when using pointer subroutine
--- Comment #4 from denney at seas dot upenn dot edu 2005-10-09 17:00 --- Created an attachment (id=9946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9946&action=view) Fixed version of code using call, nullify, etc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24286
[Bug target/24284] [4.0/4.1 regression] ICE (Segmentation fault)
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:18 --- Fixing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-09 14:02:43 |2005-10-09 17:18:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24284
[Bug tree-optimization/24287] New: pure functions cause things to be call clobbered still
Take the following source:
int g1(int);
int h(int *a, int *b)__attribute__((pure));
void link_error();
int g(void)
{
int t = 0, t1 = 2;
int t2 = h(&t, &t1);
if (t != 0)
link_error ();
if (t1 != 2)
link_error ();
g1(t2);
if (t != 0)
link_error ();
if (t1 != 2)
link_error ();
return t2 == 2;
}
We should not have link_error referenced at all.
Even on the improved aliasing branch we get:
Variable: t, UID 1278, int, is addressable, call clobbered, default def: t_1
Variable: t1, UID 1279, int, is addressable, call clobbered, default def: t1_3
That is incorrect, as t and t1 are not call clobbered as pure functions cannot
cause something to escape.
--
Summary: pure functions cause things to be call clobbered still
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24287
[Bug tree-optimization/24287] pure functions cause things to be call clobbered still
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 17:35 --- Related to PR 23134. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23134 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24287
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Comment #9 from jblomqvi at cc dot hut dot fi 2005-10-09 17:41 --- (In reply to comment #8) > Can you do timings with today's compiler? > Performance is now equivalent with g77, a factor of 500 times faster than mainline a month ago. I don't know if any of these patches have made it into 4.0. The actual timings: Original timing (with mmap): 13.6 s. Getting rid of mmap (committed 2005-09-10 or thereabouts): 0.77 s. transfer_array (committed 2005-09-24): 0.040 s sread/swrite (the patch committed 2005-10-07): 0.026 s. g77: 0.027 s ifort 9.0: 0.153 s. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug fortran/23169] INTENT information not used in the middle-end for optimizations
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 17:41 --- There are a couple of problems here. First I noticed that bar in foo is not marked as pure even though the IPA mechanism marked it as such, so that looks like a fortran front-end bug in that it has two different DECLs for the same function. The second issue after that is filed as PR 24287 which talks about pure functions causing local variables to be call clobbered even though they don't escape. This issue is related to PR 23134 also. Here is a testcase which we would not get unless we take intent(in) into account: integer function foo(b,c) integer, intent(in) :: b, c integer :: d, e d = b; e = c; call bar(b,c) foo = d-b + e-c; end function foo should always be zero as bar should not be able to touch b or c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug bootstrap/22396] bootstrap of f95 enabled gcc fails because gfortran.1 is missing
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:43 --- What is the status of this PR? I've personally never run into the problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22396
[Bug c/23087] Misleading warning, "... differ in signedness"
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-09 17:47 --- But it's platform-independent. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|sparc-sun-solaris2.9|*-*-* GCC host triplet|sparc-sun-solaris2.9|*-*-* GCC target triplet|sparc-sun-solaris2.9|*-*-* Last reconfirmed|-00-00 00:00:00 |2005-10-09 17:47:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
[Bug target/24071] __gthread_active_p vs __gthread_once
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bkoz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Component|libstdc++ |target GCC build triplet|sparc-sun-solaris2.9|*-*-solaris2.* GCC host triplet|sparc-sun-solaris2.9|*-*-solaris2.* GCC target triplet|sparc-sun-solaris2.9|*-*-solaris2.* Summary|solaris vs. |__gthread_active_p vs |__gthread_active_p |__gthread_once http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #25 from lucier at math dot purdue dot edu 2005-10-09 18:26 --- [lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -v -m64 -dynamiclib -o conftest conftest.c Using built-in specs. Target: powerpc-apple-darwin8.2.0 Configured with: ../configure powerpc-apple-darwin8.2.0 --enable-languages=c --prefix=/pkgs/gcc-mainline --with-gmp=/pkgs/gmp-4.1.4 --with-mpfr=/pkgs/gmp-4.1.4 Thread model: posix gcc version 4.1.0 20051007 (experimental) /pkgs/gcc-mainline/libexec/gcc/powerpc-apple-darwin8.2.0/4.1.0/cc1 -quiet -v -D__DYNAMIC__ conftest.c -fPIC -quiet -dumpbase conftest.c -m64 -auxbase conftest -version -o /var/tmp//ccJySvb8.s ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/../../../../powerpc-apple-darwin8.2.0/include" #include "..." search starts here: #include <...> search starts here: /pkgs/gcc-mainline/include /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/include /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C version 4.1.0 20051007 (experimental) (powerpc-apple-darwin8.2.0) compiled by GNU C version 4.1.0 20051007 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 8fa0ed40f679dd18a041425360ea4f73 as -arch ppc64 -o /var/tmp//ccpmqZ6K.o /var/tmp//ccJySvb8.s /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load -weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/ppc64 -L/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/../../../ppc64 /var/tmp//ccpmqZ6K.o -lgcc_s.10.4 -lgcc -lSystemStubs -lSystem /usr/bin/libtool: can't locate file for: -lgcc_s.10.4 /usr/bin/libtool: file: -lgcc_s.10.4 is not an object file (not allowed in a library) [lindv2:~/Desktop/gcc-test] lucier% file /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib: Mach-O fat file with 2 architectures /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib (for architecture ppc):Mach-O dynamically linked shared library stub ppc /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64 -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 18:39 --- Confirmed. The middle-end problems are almost all in reload.c. For the profile, everything is just spread all around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 18:48 --- I think this is just a problem of templates, lots of them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-09 18:48:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24288] New: Incorrect termination after exception is thrown, if compiled with -O1 -fomit-frame-pointer
When an exception is thrown the program terminates instead of catching the exception. This only happens with -O1 or higher and -fomit-frame-pointer. The problem does not occur when: - the throwing function is not virtual - the throwing function is not an operator - the throwing function does not call the non-inline base class function Disabling parts of -O1 still triggers the problem ( -fno-defer-pop -fno-merge-constants -fno-thread-jumps -fno-loop-optimize -fno-if-conversion -fno-if-conversion2 -fno-guess-branch-probability -fno-cprop-registers ) Output of attached test-case with -O: # throwing... CATCHED UNKNOWN EXCEPTION. Output of attached test-case with -O1 -fomit-frame-pointer: # throwing... terminate called after throwing an instance of 'std::range_error' what(): Test exception. Aborted -- Summary: Incorrect termination after exception is thrown, if compiled with -O1 -fomit-frame-pointer Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bduerner at gmx dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24288
[Bug c++/24288] Incorrect termination after exception is thrown, if compiled with -O1 -fomit-frame-pointer
--- Comment #1 from bduerner at gmx dot de 2005-10-09 19:08 --- Created an attachment (id=9947) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9947&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24288
[Bug middle-end/24288] Incorrect termination after exception is thrown, if compiled with -O1 -fomit-frame-pointer
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 19:09 --- I think this has been fixed for 4.0.0, won't know until there is a testcase. Oh, this is more of an interaction between fomit-frame-pointer and eh tables. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24288
[Bug libgcj/24289] New: libjava fails to build if GNU make 3.81 betas are used (caused by feature addition, not bug, in 3.81beta --> will still happen with 3.81 final)
The problem is this new feature in make: * WARNING: Backward-incompatibility! GNU make now implements a generic "second expansion" feature on the prerequisites of both explicit and implicit (pattern) rules. After all rules have been parsed the prerequisites are expanded again, this time with all the automatic variables in scope. This means that in addition to using standard SysV $$@ in prerequisites lists, you can also use complex functions such as $$(notdir $$@) etc. This behavior applies to implicit rules, as well, where the second expansion occurs after the rule is matched. However, this means that you need to double-quote any "$" in your filenames; instead of "foo: boo$$bar" you now must write "foo: foobar". The presence of this feature can be detected using ifneq (,$(filter second-expansion,$(.FEATURES))) (not sure how compatible that is with non-GNU makes though) -- Summary: libjava fails to build if GNU make 3.81 betas are used (caused by feature addition, not bug, in 3.81beta --> will still happen with 3.81 final) Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24289
[Bug libgcj/24289] libjava fails to build if GNU make 3.81 betas are used (caused by feature addition, not bug, in 3.81beta --> will still happen with 3.81 final)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 19:33 --- This is a dup of bug 23292. *** This bug has been marked as a duplicate of 23292 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24289
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 19:33 --- *** Bug 24289 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 19:34 --- Can you guys really report this to GNU make and say that this should not change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-10-09 19:35 --- Created an attachment (id=9948) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9948&action=view) Patch for no-overflow analysis from signedness -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug libfortran/24174] real(10) array output broken
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-10-09 19:35 --- (In reply to comment #5) > > It should be noted that the patch assumes that the padding for real(10) is > > 10 > > bytes data + 2 bytes padding. This works on i686-Linux, might not work on > > other > > targets (big endian?). > > Itanium has padding to 16 bytes for 10-byte reals. > > Using 12 bytes for 10-byte reals on ia686 would mean breaking binary > compatibility with Itanium :-( Oh dear.. Is there any functionality one can use to get information about padding (size, location of pad bytes etc.), or do we need to resort to lots of #ifdef kludging? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-09 19:36 --- Note this will cause problems more with java than it does with any other language since $ is normal in class files as it is used for inner classes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-10-09 19:36 --- With the recent changes to scev analysis that ensure that signed chrecs do not wrap (assuming -fno-wrapv), it is fairly easy to get tree level # of iterations analysis to use this fact, see the attached patch. This does not directly help doloop opts that work on rtl, though. There are two possible solutions: 1) Rewrite the loop on tree level to a form that is easier to analyse, e.g., for (i = 0; i != n + 1; i++) 2) Somehow pass the information that the loop is not infinite (or even that its control iv does not wrap) to rtl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug tree-optimization/24226] [4.1 Regression] ICE: Segmentation fault in operand_equal_p (complete loop unrolling)
--- Comment #8 from rakdver at gcc dot gnu dot org 2005-10-09 19:38 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00478.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24226
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-09 20:00 --- Just for future references I wrote something in: http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=13781 Complaining about the situational. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
[Bug ada/24290] New: [4.1 Regression] ACATS ICE c64104c
I missed it but it started failing between: LAST_UPDATED: Mon Sep 12 07:44:40 UTC 2005 LAST_UPDATED: Thu Sep 15 20:35:53 UTC 2005 /home/guerby/work/gcc/build/build-20050915T230254/gcc/xgcc -c -B/home/guerby/work/gcc/build/build-20050915T230254/gcc/ -gnatws -O2 -I/home/guerby/work/gcc/build/build-20050915T230254/gcc/testsuite/ada/acats/support c64104c.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) -- Summary: [4.1 Regression] ACATS ICE c64104c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24290
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 20:47 ---
Even further reduced testcase:
struct _Words {_Words();};
_Words _M_local_word[2];
---
This shows up while bootstrapping on x86_64-pc-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug c++/24291] New: problem with std::stringstream
This code:
#include
#include
int main() {
std::cerr << static_cast(std::stringstream() << "foo"
<< "bar").str() << "\n";
return 0;
}
prints:
~/ootbc/members/src$ a.out
0x8048c58bar
The "foo" operand is being formatted as a pointer rather than a C string.
Strangely, the second "bar" operand is formatted correctly.
Ivan
--
Summary: problem with std::stringstream
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24291
[Bug libfortran/24174] real(10) array output broken
--- Comment #7 from jblomqvi at cc dot hut dot fi 2005-10-09 20:52 --- (In reply to comment #5) > > It should be noted that the patch assumes that the padding for real(10) is > > 10 > > bytes data + 2 bytes padding. This works on i686-Linux, might not work on > > other > > targets (big endian?). > > Itanium has padding to 16 bytes for 10-byte reals. > > Using 12 bytes for 10-byte reals on ia686 would mean breaking binary > compatibility with Itanium :-( Indeed, looking at http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options it seems that x86-64 also pads real(10) to 16 bytes. See the doc for the -m128bit-long-double switch. -- jblomqvi at cc dot hut dot fi changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug c++/24291] problem with std::stringstream
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-09 20:54 --- *** This bug has been marked as a duplicate of 9925 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24291
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-09 20:54 --- *** Bug 24291 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm, obj-c++.dg/layout-1.mm fails with the GNU runtime
--- Comment #4 from christian dot joensson at gmail dot com 2005-10-09 20:59 --- Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
[Bug testsuite/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09 21:00 --- Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23613
[Bug objc++/23614] obj-c++.dg/lookup-2.mm fails with the GNU runtime
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09 21:00 --- Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23614
[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime
--- Comment #4 from christian dot joensson at gmail dot com 2005-10-09 21:00 --- Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #2 from christian dot joensson at gmail dot com 2005-10-09 21:00 --- Also here... http://gcc.gnu.org/ml/gcc/2005-10/msg00198.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug libfortran/24174] real(10) array output broken
--- Comment #8 from jblomqvi at cc dot hut dot fi 2005-10-09 21:29 --- Well, a slightly less broken approach than the patch in #3 would be to use sizeof(GFC_REAL_10) and sizeof(GFC_COMPLEX_10) instead of hardcoded sizes. But the problem with this would still be 1) location of pad bytes and 2) changing the ABI with -m128bit-long-double or similar switches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #5 from sabre at nondot dot org 2005-10-09 22:02 --- Some updates: the -ftime-report problems were a local problem with apple's gcc, now fixed. This testcase has some templates (e.g. the match stuff), but mostly it is just big branchy compiler code :), not atypical of many C++ programs. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug java/22460] GCJ produces mis-match (non compatible) types in MODIFY_EXPR (from byte-code)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22460
[Bug tree-optimization/24226] [4.1 Regression] ICE: Segmentation fault in operand_equal_p (complete loop unrolling)
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-09 22:50 --- Subject: Bug 24226 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-09 22:50:01 Modified files: gcc: ChangeLog tree-cfg.c tree-flow.h tree-ssa-loop-niter.c Log message: PR tree-optimization/24226 * tree-cfg.c (remove_bb): Clean up unreachable loops. * tree-flow.h (free_numbers_of_iterations_estimates_loop): Declare. * tree-ssa-loop-niter.c (free_numbers_of_iterations_estimates_loop): Export. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10127&r2=2.10128 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.222&r2=2.223 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.137&r2=2.138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gcc&r1=2.45&r2=2.46 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24226
[Bug tree-optimization/21445] [meta-bug] we need a reassociate pass
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445
[Bug middle-end/18667] ice with --parm integer-share-limit=0
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18667
[Bug pending/10720] Fwd: c/10719: invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-09 22:52 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10720
[Bug pending/10720] Fwd: c/10719: invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 22:52 --- Mark as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10720
[Bug target/7321] [x86 3Dnow]ice on vectors with -O3 and -m3dnow
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7321
[Bug c/24292] New: Can't build qemu 0.7.2
Trying to build qemu 0.7.2 gives the following error:
/tmp/qemu-0.7.2/target-i386/ops_sse.h: In function 'op_pshufw_mmx':
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: unable to find a register to
spill in class 'GENERAL_REGS'
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: this is the insn:
(insn:HI 18 17 19 0 /tmp/qemu-0.7.2/target-i386/ops_sse.h:569 (set
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
(mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
(const_int 2 [0x2]))
(reg/v/f:SI 59 [ s ])) [0 ._w S2 A16])) 52
{*movstricthi_1} (insn_list:REG_DEP_TRUE 16 (insn_list:REG_DEP_TRUE 12
(insn_list:REG_DEP_TRUE 53 (nil
(expr_list:REG_DEAD (reg:SI 64)
(nil)))
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: confused by earlier errors, bailing
out
make[1]: *** [op.o] Error 1
The related code appears to be:
void OPPROTO glue(op_pshufw, SUFFIX) (void)
{
Reg r, *d, *s;
int order;
d = (Reg *)((char *)env + PARAM1);
s = (Reg *)((char *)env + PARAM2);
order = PARAM3;
r.W(0) = s->W(order & 3);
r.W(1) = s->W((order >> 2) & 3);
r.W(2) = s->W((order >> 4) & 3);
r.W(3) = s->W((order >> 6) & 3);
*d = r;
}
My version information is:
[EMAIL PROTECTED]:/tmp/qemu-0.7.2$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
qemu can be found at qemu.org; I had unpacked qemu, cd'd into the directory,
and unpacked kqemu into it, then ran ./configure and make, each with no
options, as the kqemu documentation says.
--
Summary: Can't build qemu 0.7.2
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
[Bug target/24292] Can't build qemu 0.7.2
--- Comment #1 from nigelenki at comcast dot net 2005-10-09 23:49 --- Created an attachment (id=9949) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9949&action=view) the dot-i file thingy you guys wanted the thingy that appeared in a completely different directory than related .c and .h files o.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
[Bug target/24292] Can't build qemu 0.7.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-10 00:21 ---
Reduced testcase:
register struct CPUX86State *env asm("ebp");
register unsigned long T0 asm("ebx");
register unsigned long T1 asm("esi");
register unsigned long T2 asm("edi");
extern int __op_param1, __op_param2, __op_param3;
void op_movq(void)
{
unsigned long long*d, *s;
d = (unsigned long long *)((char *)env + ((long)(&__op_param1)));
s = (unsigned long long *)((char *)env + ((long)(&__op_param2)));
*d = *s;
}
-
Hmm, you are starving the RA, so in a way this is not a bug. There is a dup of
this bug too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
[Bug target/24292] Can't build qemu 0.7.2
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 00:22 --- This is a dup of bug 16185. *** This bug has been marked as a duplicate of 16185 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
[Bug target/16185] ICE: in spill_failure, at reload1.c:1892, global registers and long long
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-10 00:22 --- *** Bug 24292 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nigelenki at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16185
[Bug c/24293] New: Undefined behaviour not diagnosed with -fsyntax-only
GCC does not diagnose the following translation unit with -fsyntax-only: static struct foo x; -- Summary: Undefined behaviour not diagnosed with -fsyntax-only Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
[Bug bootstrap/24294] New: Configure error while bootstrapping
I updated gcc from CVS today (2005-10-09) and configured with ~/src/gcc/configure --prefix=$HOME/gcc --with-mpfr=/Users/eschnett --enable-languages=c,c++,fortran,java,objc,treelang A "make bootstrap" aborts after some time with configure: creating ./config.status config.status: creating Makefile config.status: creating include/Makefile config.status: creating libmath/Makefile config.status: creating libsupc++/Makefile config.status: creating src/Makefile config.status: creating po/Makefile config.status: creating testsuite/Makefile config.status: creating scripts/testsuite_flags config.status: creating config.h config.status: executing default-1 commands Adding multilib support to Makefile in /Users/eschnett/src/gcc/libstdc++-v3 multidirs=ppc64 with_multisubdir= Running configure in multilib subdirs ppc64 pwd: /Users/eschnett/src/gcc-build/powerpc-apple-darwin8.2.0/libstdc++-v3 Running configure in multilib subdir ppc64 pwd: /Users/eschnett/src/gcc-build/powerpc-apple-darwin8.2.0 mkdir ppc64 configure: creating cache ./config.cache checking build system type... powerpc-apple-darwin8.2.0 checking host system type... powerpc-apple-darwin8.2.0 checking target system type... powerpc-apple-darwin8.2.0 checking for a BSD-compatible install... /sw/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for powerpc-apple-darwin8.2.0-gcc... /Users/eschnett/src/gcc-build/./gcc/xgcc -B/Users/eschnett/src/gcc-build/./gcc/ -B/Users/eschnett/gcc/powerpc-apple-darwin8.2.0/bin/ -B/Users/eschnett/gcc/powerpc-apple-darwin8.2.0/lib/ -isystem /Users/eschnett/gcc/powerpc-apple-darwin8.2.0/include -isystem /Users/eschnett/gcc/powerpc-apple-darwin8.2.0/sys-include -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-target-libstdc++-v3] Error 1 make[1]: *** [all] Error 2 make: *** [bootstrap] Error 2 The file "config.log" contains no clues. I'm trying to bootstrap with $ gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1809) -- Summary: Configure error while bootstrapping Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.2.0 GCC host triplet: powerpc-apple-darwin8.2.0 GCC target triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24294
[Bug bootstrap/24294] Configure error while bootstrapping
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-10 01:48 --- Starting with 4.1, if you don't have a 64bit machine and you have Mac OS X 10.4 (aka darwin8.2), you have to use --disable-multilib . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24294
[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-10 01:53 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||2.95.3 3.0.4 3.2.2 3.2.3 ||3.3.1 4.0.0 3.4.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-10-10 01:53:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
[Bug bootstrap/19289] ice during gcc4-20050102 profiledboostrap.
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 02:33 --- I think this is a bug in your SPEC for RPM's. Can you make sure that your RPM mechanism is not touching a file which should not be touched. >From what I hear is that a profiledbootstrap/install works fine when not doing the RPM mechanism at all but by hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19289
[Bug bootstrap/19289] ice during gcc4-20050102 profiledboostrap.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19289
[Bug target/20928] [4.0/4.1 regression] ICE: unrecognizable insns
--- Comment #13 from kazu at gcc dot gnu dot org 2005-10-10 03:20 --- The testcase in comment #8 still triggers an ICE if run with -O -mtune=k8 -fPIC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-10 04:29 --- Only a hppa-linux bug now, which means this should be targetted at 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal GCC target triplet||hppa-linux Target Milestone|4.0.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug tree-optimization/24226] [4.1 Regression] ICE: Segmentation fault in operand_equal_p (complete loop unrolling)
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-10 04:35 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24226
[Bug middle-end/24288] [3.4 Regression] Incorrect termination after exception is thrown, if compiled with -O1 -fomit-frame-pointer
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 04:48 --- Only a 3.4.x regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||3.4.0 Known to work||4.1.0 4.0.0 3.3.3 Summary|Incorrect termination after |[3.4 Regression] Incorrect |exception is thrown, if |termination after exception |compiled with -O1 -fomit- |is thrown, if compiled with |frame-pointer |-O1 -fomit-frame-pointer Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24288
[Bug tree-optimization/21655] g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0 fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 04:54 --- This has been xfailed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization, xfail Last reconfirmed|2005-05-21 14:03:59 |2005-10-10 04:54:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21655
[Bug middle-end/20506] verify_stmts calls error() on internal errors(notes)
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 04:59 --- maybe we should be using verbatim or note. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-06-18 01:23:36 |2005-10-10 04:59:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20506
[Bug driver/21979] Preprocessing fortran files has some flaws
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 05:01 --- I am going to mark this as a dup of bug 23861 since that has the reference to the patch which fixes this. *** This bug has been marked as a duplicate of 23861 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21979
[Bug driver/23861] Build failure due to "-pipe" not working with .F90 and .F95 files
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-10 05:01 --- *** Bug 21979 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug libfortran/20438] Reconfiguring of libgfortran fails "conflicting types for int8_t"
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-10 05:08 --- Is this true any more on the mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
