[Bug tree-optimization/29777] New: missed optimization: model missing widen_mult* idioms for SSE
The patch that adds support for vectorization of multiple data-types (http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00166.html) was missing a few bits from the i386 port that rth contributed to autovect-branch a while back. This is because a couple testcases were failing with these features: The testcases that failed (on assembler error) are two of tests that require "vect_widen_mult_hi_to_si": testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c testsuite/gcc.dg/vect/vect-widen-mult-s16.c testsuite/gcc.dg/vect/vect-widen-mult-sum.c The missing insns (that should be merged from autovect-branch and debugged): vec_widen_umult_hi_v8hi vec_widen_umult_lo_v8hi When these are back in, we'll want to add i?86-*-* and x86_64-*-* to the list of targets that return true in the function "vect_widen_mult_hi_to_si" in testsuite/lib/target-support.exp. -- Summary: missed optimization: model missing widen_mult* idioms for SSE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: i?86-*-* and x86_64-*-* GCC host triplet: i?86-*-* and x86_64-*-* GCC target triplet: i?86-*-* and x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #19 from rsandifo at gcc dot gnu dot org 2006-11-09 09:34 --- Patch posted for review. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||11/msg00548.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug fortran/28122] Undocumented gfortran options
--- Comment #1 from brooks at gcc dot gnu dot org 2006-11-09 09:41 --- -qkind= has been removed, and thus it no longer needs documentation. -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-11 07:57:10 |2006-11-09 09:41:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28122
[Bug fortran/28122] Undocumented gfortran options
--- Comment #2 from brooks at gcc dot gnu dot org 2006-11-09 09:48 --- -fpreprocessed seems to be intended for internal use between gfortran and f951, to indicate that the file has been preprocessed and the original filename should be read from it. Thus, it should probably be set to Undocumented in lang.opt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28122
[Bug c/29771] u != '\377' always true (u is unsigned char)
--- Comment #3 from schwab at suse dot de 2006-11-09 10:00 --- And '\377' < 0, so the warning is correct. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29771
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #17 from irar at il dot ibm dot com 2006-11-09 10:15 --- I applied the patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html (a fix for PR26197). The bootstrap with vectorization passes! However, the failure in comment #3 still occurs in the later revisions. So, I am going to hunt for a later patch that broke bootstrap with vectorization (applying the above patch). Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug tree-optimization/29778] New: missed optimization: model missing vec_pack/unpack idioms for ia64
We need to port the ia64 support for vectorization of multiple-datatypes from autovect-branch. This is the patch missing from mainline (wasn't included in http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00166.html cause I cauldn't test this): 2005-12-02 Richard Henderson <[EMAIL PROTECTED]> * config/ia64/ia64.c (TARGET_VECTORIZE_BUILTIN_EXTRACT_EVEN): New. (TARGET_VECTORIZE_BUILTIN_EXTRACT_ODD): New. (TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN, TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD, ia64_builtin_mul_widen_even, ia64_builtin_mul_widen_odd, builtin_ia64_pmpy_r, builtin_ia64_pmpy_l, IA64_BUILTIN_PMPY_R, IA64_BUILTIN_PMPY_L): New (ia64_init_builtins): Initialize builtin_ia64_pmpy_[rl]. (ia64_expand_builtin): Expand them. (ia64_expand_unpack): New. * config/ia64/vect.md (smulv4hi3_highpart, umulv4hi3_highpart): New. (vec_pack_ssat_v4hi): Rename from pack2_sss. (vec_pack_usat_v4hi): Rename from pack2_uss. (vec_pack_ssat_v2si): Rename from pack4_sss. (vec_pack_mod_v4hi, vec_pack_mod_v2si): New. (vec_interleave_lowv8qi): Rename from unpack1_l. (vec_interleave_highv8qi): Rename from unpack1_h. (vec_interleave_lowv4hi): Rename from unpack2_l. (vec_interleave_highv4hi): Rename from unpack2_h. (vec_interleave_lowv2si): Rename from unpack4_l. (vec_interleave_highv2si): Rename from unpack4_h. (vec_unpacku_hi_v8qi, vec_unpacks_hi_v8qi): New. (vec_unpacku_lo_v8qi, vec_unpacks_lo_v8qi): New. (vec_unpacku_hi_v4hi, vec_unpacks_hi_v4hi): New. (vec_unpacku_lo_v4hi, vec_unpacks_lo_v4hi): New. * config/ia64/ia64-protos.h (ia64_expand_unpack): Declare. Once the above is merged, we can add ia64 to the lists of targets that support the following functions in testsuite/lib/target-support.exp: check_effective_target_vect_sdot_hi check_effective_target_vect_udot_qi check_effective_target_vect_sdot_qi check_effective_target_vect_widen_sum_qi_to_hi check_effective_target_vect_widen_sum_hi_to_si -- Summary: missed optimization: model missing vec_pack/unpack idioms for ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: ia64-*-* GCC host triplet: ia64-*-* GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29778
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-11-09 11:16
---
> I am playing with some ideas how to fix this, unless I come up with
something
> soon, I will revert the patch (except for the testcase that I would like to
> remain in the testsuite).
The best I was able to do is the following patch. Virtual operand prunning
removes all the symbols that the SMTs have in common, which causes this PR.
The patch adds artificial "conflict" symbols to all pairs of aliasing SMTs, to
avoid this. Just looking at the dump of the testcase for this PR, it appears
quite expensive (there are a lot of new virtual operands); I will check what
the memory behavior is on larger testcases.
Index: tree-dump.c
===
*** tree-dump.c (revision 118619)
--- tree-dump.c (working copy)
*** dequeue_and_dump (dump_info_p di)
*** 495,500
--- 495,501
case SYMBOL_MEMORY_TAG:
case NAME_MEMORY_TAG:
case STRUCT_FIELD_TAG:
+ case CONFLICT_TAG:
break;
case VAR_DECL:
Index: tree-pretty-print.c
===
*** tree-pretty-print.c (revision 118619)
--- tree-pretty-print.c (working copy)
*** dump_generic_node (pretty_printer *buffe
*** 849,854
--- 849,855
break;
case SYMBOL_MEMORY_TAG:
+ case CONFLICT_TAG:
case NAME_MEMORY_TAG:
case STRUCT_FIELD_TAG:
case VAR_DECL:
Index: tree.c
===
*** tree.c (revision 118619)
--- tree.c (working copy)
*** init_ttree (void)
*** 270,279
--- 270,281
tree_contains_struct[STRUCT_FIELD_TAG][TS_DECL_MINIMAL] = 1;
tree_contains_struct[NAME_MEMORY_TAG][TS_DECL_MINIMAL] = 1;
tree_contains_struct[SYMBOL_MEMORY_TAG][TS_DECL_MINIMAL] = 1;
+ tree_contains_struct[CONFLICT_TAG][TS_DECL_MINIMAL] = 1;
tree_contains_struct[STRUCT_FIELD_TAG][TS_MEMORY_TAG] = 1;
tree_contains_struct[NAME_MEMORY_TAG][TS_MEMORY_TAG] = 1;
tree_contains_struct[SYMBOL_MEMORY_TAG][TS_MEMORY_TAG] = 1;
+ tree_contains_struct[CONFLICT_TAG][TS_MEMORY_TAG] = 1;
tree_contains_struct[STRUCT_FIELD_TAG][TS_STRUCT_FIELD_TAG] = 1;
*** tree_code_size (enum tree_code code)
*** 336,341
--- 338,344
return sizeof (struct tree_function_decl);
case NAME_MEMORY_TAG:
case SYMBOL_MEMORY_TAG:
+ case CONFLICT_TAG:
return sizeof (struct tree_memory_tag);
case STRUCT_FIELD_TAG:
return sizeof (struct tree_struct_field_tag);
*** tree_node_structure (tree t)
*** 2119,2124
--- 2122,2128
case SYMBOL_MEMORY_TAG:
case NAME_MEMORY_TAG:
case STRUCT_FIELD_TAG:
+ case CONFLICT_TAG:
return TS_MEMORY_TAG;
default:
return TS_DECL_NON_COMMON;
Index: tree.h
===
*** tree.h (revision 118619)
--- tree.h (working copy)
*** extern const enum tree_code_class tree_c
*** 106,112
#define MTAG_P(CODE) \
(TREE_CODE (CODE) == STRUCT_FIELD_TAG \
|| TREE_CODE (CODE) == NAME_MEMORY_TAG \
!|| TREE_CODE (CODE) == SYMBOL_MEMORY_TAG)
/* Nonzero if DECL represents a VAR_DECL or FUNCTION_DECL. */
--- 106,113
#define MTAG_P(CODE) \
(TREE_CODE (CODE) == STRUCT_FIELD_TAG \
|| TREE_CODE (CODE) == NAME_MEMORY_TAG \
!|| TREE_CODE (CODE) == SYMBOL_MEMORY_TAG \
!|| TREE_CODE (CODE) == CONFLICT_TAG)
/* Nonzero if DECL represents a VAR_DECL or FUNCTION_DECL. */
Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 118619)
--- tree-ssa-alias.c(working copy)
*** init_alias_info (void)
*** 915,920
--- 915,925
|| TREE_CODE (var) == SYMBOL_MEMORY_TAG
|| !is_global_var (var))
clear_call_clobbered (var);
+
+ /* Mark all old conflict symbols for renaming, so that they go
+away. */
+ if (TREE_CODE (var) == CONFLICT_TAG)
+ mark_sym_for_renaming (var);
}
/* Clear flow-sensitive points-to information from each SSA name. */
*** compute_flow_sensitive_aliasing (struct
*** 1149,1154
--- 1154,1265
}
}
+ /* Element of the conflicts hashtable. */
+
+ typedef struct
+ {
+ hashval_t hash;
+ tree smt1, smt2;
+ } smt_pair;
+
+ typedef smt_pair *smt_pair_p;
+
+ /* Return true if the smt pairs are equal. */
+
+ static int
+ smt_pair_eq (const void *va, const void *vb)
+ {
+ const smt_pair_p a = (const smt_pair_p) va;
+ const smt_pair_p b = (const smt_pair_p) vb;
+ return (a->smt1 == b->smt1 && a->smt2 == b->smt2);
+ }
+
+ /* Hash for a smt pair. */
+
+ static u
[Bug middle-end/29779] New: vectorizer fortran testcases failing
Looks like sometime between Oct27
(http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01336.html)
and Oct30
(http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01538.html)
the fortran vectorizer testcases started ICEing on:
gfortran.dg/vect/vect-3.f90:0: warning: 'const' attribute directive ignored
gfortran.dg/vect/vect-3.f90:4: internal compiler error: in
vect_setup_realignment, at tree-vect-transform.c:2534
Should be related somehow to this code in rs6000.c:
/* Initialize target builtin that implements
targetm.vectorize.builtin_mask_for_load. */
decl = add_builtin_function ("__builtin_altivec_mask_for_load",
v16qi_ftype_long_pcvoid,
ALTIVEC_BUILTIN_MASK_FOR_LOAD,
BUILT_IN_MD, NULL,
tree_cons (get_identifier ("const"),
NULL_TREE, NULL_TREE));
Anybody knows which patch caused this?
--
Summary: vectorizer fortran testcases failing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ppc*-*-linux
GCC host triplet: ppc*-*-linux
GCC target triplet: ppc*-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug c++/29780] New: temporary file breaks cross-build
Hi, When performing a cross-build (see the triplets I entered above), a file named "as" gets created which gets used instead of the right assembler, thus breaking the build. Pls. note that I've entered the target triplets we're building (see http://cegcc.sourceforge.net), this gcc build bug is probably unrelated to them. I've had to work around this by using a script such as the one pasted below. I've reported this to the mailing list months ago (see http://gcc.gnu.org/ml/gcc/2006-07/msg00533.html ) but someone asked me a couple of days ago whether I created a bugzilla report, and I don't think I did. So I'm making up for that now. Here's the script I use as workaround : mkdir -p $BUILD_DIR/gpp || exit 1 cd $BUILD_DIR/gpp || exit 1 # export CFLAGS="" # $TOP_SRCDIR/src/gcc/configure \ --prefix=$PREFIX \ --enable-languages=c,c++ \ --disable-interwork \ --disable-nls \ --enable-checking \ --disable-multilib \ --build=$MY_HOST_ARCH --target=$TGT_ARCH || exit 1 # # Deliberately no error handling here. # make # # Because we need to delete this file # rm $BUILD_DIR/gpp/gcc/as || exit 1 # # Now the build should continue smoothly # make || exit 1 exit 0 -- Summary: temporary file breaks cross-build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danny dot backx at scarlet dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-wince-pe, arm-wince-mingw32ce, arm-wince-cegcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29780
[Bug c++/29780] temporary file breaks cross-build
--- Comment #1 from valentin dot longchamp at gmail dot com 2006-11-09 12:15 --- I'm the guy who asked him about the bug report. The same happened to me with a "armv6-angstrom-linux-gnueabi" target (angstrom is a openembedded based distribution). I used the same fix (removing the as shell script) successfully -- valentin dot longchamp at gmail dot com changed: What|Removed |Added CC||valentin dot longchamp at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29780
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2006-11-09 12:33 --- > Things are still broken on hppa-linux. I have a fix (in the linker) for the !HAVE_COMDAT_GROUP breakage on x86 but it is probably not sufficient on hppa. Could you try it anyway? Just relink the libstdc++.so shared object with the patched linker. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2006-11-09 12:34 --- Created an attachment (id=12575) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12575&action=view) Linker fix for !HAVE_COMDAT_GROUP breakage Successfully tested on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #8 from sergstesh at yahoo dot com 2006-11-09 13:41 --- I looked into source code of 'test_summary' script and it indeed calls the 'Mail' program, the one with capital 'M'. I have never heard of it, I am familiar with 'mail' with small 'm'. On my system it's lrwxrwxrwx 1 root root 14 Jan 12 2006 /usr/bin/Mail -> ../../bin/mail . Is it OK ? I tried ../gcc-3.4.6.src/contrib/test_summary -p /dev/null -m [EMAIL PROTECTED] -f | sh - pay attention to '-f', and nothing happens. No mail is sent, no messages on screen. How can I regenerate the Email text produced by the first invokation of 'test_summary' ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug ada/29781] New: -O3 -gnatVa triggers a bug box on working Dragonchess code
I've added the bug box and the code below. This code compiled fine with
previous versions of GNAT, and with -O2 or without -gnatVa.
gcc-4.1 -c -I./ -gnatVa -O3 iterate_moves.adb
+===GNAT BUG DETECTED==+
| 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) (x86_64-pc-linux-gnu) GCC
error:|
| in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111 |
| Error detected at iterate_moves.adb:147:1|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc-4.1 or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
iterate_moves.adb
iterate_moves.ads
board_types.ads
iterate_moves-next_piece.adb
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380
with Interfaces;
-- Board_Types contains all the fundamental types representing the game.
package Board_Types is
-- Board_Types is and should continue to be conceptually pure. No
-- global data or state.
pragma Pure (Board_Types);
type Board_Layer_Type is (Upper, Middle, Lower);
type Piece_Type is
(Sylph, Griffon,
Dragon, King, Mage, Paladin, Thief,
Cleric, Hero, Unicorn, Oliphant, Warrior, Dwarf, Basilisk,
Elemental);
type Player_Type is (Scarlet, Gold);
type Board_Piece (Exists : Boolean := False) is record
case Exists is
when True =>
Piece : Piece_Type;
Player : Player_Type;
when False =>
null;
end case;
end record;
type Row_Type is range 1 .. 8;
type Column_Type is range 1 .. 12;
type Board_Layer is array (Row_Type, Column_Type) of Board_Piece;
type Board is array (Board_Layer_Type) of Board_Layer;
type Board_Location is record
Layer : Board_Layer_Type;
Row : Row_Type;
Column : Column_Type;
end record;
Initial_Board : constant Board := (others => (others => (others => (Exists
=> False;
-- Helper functions
function "not" (P : Player_Type) return Player_Type;
pragma Inline ("not");
end Board_Types;
-- with Validate; use Validate;
package body Iterate_Moves is
function Next_Piece (C: Player_Type; Piece: Board_Location; B : Board)
return Board_Location
is separate;
subtype Int is Integer;
-- Pawn_Advance/Retreat is to avoid having two type conversions
-- all over the place. They should be completely inlined.
function Pawn_Advance (R : Row_Type; C : Player_Type) return Row_Type is
begin
if C = Scarlet then
return R - 1;
else
return R + 1;
end if;
end Pawn_Advance;
pragma Inline (Pawn_Advance);
function Pawn_Retreat (R : Row_Type; C : Player_Type) return Row_Type is
begin
if C = Scarlet then
return R + 1;
else
return R - 1;
end if;
end Pawn_Retreat;
pragma Inline (Pawn_Retreat);
function Increment (C : Player_Type; I : Board_Move; B : Board)
return Board_Move;
function Inc (C : Player_Type; Start : Board_Location; B :Board)
return Board_Move
is
begin
return Increment
(C,
(Next_Piece (C, Start, B), (Upper, 1, 1), Increment, 0),
B);
end Inc;
pragma Inline (Inc);
function Sylph_Increment
(C : Player_Type; Start : Board_Location; Move_Number_In : Natural; B :
Board)
return Board_Move
is
Move_Number : Natural := Move_Number_In;
Orig_Row : Row_Type;
begin
if (Start.Layer = Upper and Move_Number > 4) or
(Start.Layer = Middle and Move_Number > 7) then
return Inc (C, Start, B);
end if;
case Start.Layer is
when Upper =>
loop
case Move_Number is
when others =>
raise Program_Error;
end case;
end loop;
when Middle =>
if C = Scarlet then
Orig_Row := 7;
else
Orig_Row := 2;
end if;
loop
case Move_Number is
when 1 =>
if not B (Upper) (Start.Row, Start.Column).Exists then
return (Start,
(Upper, Start.Row, Start.Column),
True_Move, Move_
[Bug libgcj/9866] static nested class refers to private member of outer class
--- Comment #6 from pmladek at suse dot cz 2006-11-09 14:16 --- I still see the problem with gcj (GCC) 4.1.2 20061018 (prerelease) (SUSE Linux). It makes problems also with OpenOffice.org when the internally used hsqldb is compiled and used with gcj/gij. Note that it is really a bug. The java documentation says at http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html: --- cut --- A nested class is a member of its enclosing class and, as such, has access to other members of the enclosing class, even if they are declared private. --- cut --- There is another definition in the "Java Language Specification" at http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1: --- cut --- Otherwise, if the member or constructor is declared private, then access is permitted if and only if it occurs within the body of the top level class (§7.6) that encloses the declaration of the member or constructor. --- cut --- Note that also C++ works this way. The OPOSITE problem is even mentioned in the "Frequently reported non-bugs" at http://gcc.gnu.org/bugs.html#nonbugs_cxx: --- cut --- Nested classes can access private members and types of the containing class. Defect report 45 clarifies that nested classes are members of the class they are nested in, and so are granted access to private members of that class. --- cut --- -- pmladek at suse dot cz changed: What|Removed |Added CC||pmladek at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9866
[Bug fortran/29713] [4.2 Regression] ICE in gfc_set_constant_character_len decl.c:762
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-09 14:29 --- Subject: Bug 29713 Author: burnus Date: Thu Nov 9 14:28:59 2006 New Revision: 118620 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118620 Log: 2006-11-09 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29713 * expr.c (gfc_simplify_expr): Correct memory allocation. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
[Bug fortran/29713] [4.1 Regression] ICE in gfc_set_constant_character_len decl.c:762
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-09 14:38 --- I checked this now into 4.2. (I somehow thought it had already been checked in and was looking too long at the wrong place to find this regression.) Remains to be done for 4.1. By the way as gfortran.dg/constant_substring.f is already part of GCC (at least 4.3 and 4.2) the extra testcase was not needed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regression] ICE in |[4.1 Regression] ICE in |gfc_set_constant_character_l|gfc_set_constant_character_l |en decl.c:762 |en decl.c:762 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-11-09 15:06
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 11:16:12 -, rakdver at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #20 from rakdver at gcc dot gnu dot org 2006-11-09 11:16
> ---
> > I am playing with some ideas how to fix this, unless I come up with
> something
> > soon, I will revert the patch (except for the testcase that I would like to
> > remain in the testsuite).
>
> The best I was able to do is the following patch. Virtual operand prunning
> removes all the symbols that the SMTs have in common, which causes this PR.
> The patch adds artificial "conflict" symbols to all pairs of aliasing SMTs, to
> avoid this.
This is what I was trying to do originally with multiple NONLOCAL
symbols (SMT's are going to go away) in the other testcase.
It is just too expensive generally
One thing i'm going to try later is to try to partition all the
stores/load statements and figure out how many symbols it takes to
represent the results exactly (IE one symbol for each set of
statements that must interfere with each other, where each statement
can be in multiple partitions).
IE if you had
load/store statements a, b, c, d
a interferes with c and d but not b
b interferes with d
You get partitions:
part1: {a, c, d}
part2: {b, d}
We then just create two symbols, and use those as the vdef/vuse syms.
This scheme is N^2 worst case, but you can choose to unify partitions
to cut down the number of symbols.
Partitions that have no shared members can also share symbols.
This would unify all of our points-to/access_can_touch_var/etc results
into one nice framework that gets very good results, and avoid the
virtual operand explosion, i think.
The real thing is that this is probably too expensive to compute 5
times per function.
We'll see.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #22 from dnovillo at redhat dot com 2006-11-09 15:08 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc Daniel Berlin wrote on 11/09/06 10:05: > One thing i'm going to try later is to try to partition all the > stores/load statements and figure out how many symbols it takes to > represent the results exactly (IE one symbol for each set of > statements that must interfere with each other, where each statement > can be in multiple partitions). > This is what I'm doing in memory SSA. More details later this week after I'm done testing and such. The difference is that partitioning is embedded in the actual SSA form and the partitioning heuristic can be changed independently of the renamer. This will let us play with a slider-style throttling for precision/compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic, ice-on-valid- ||code Summary|vectorizer fortran testcases|[4.3 Regression] vectorizer |failing |fortran testcases failing Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug bootstrap/29780] temporary file breaks cross-build
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-09 15:17 --- What version of GCC are you building? This works for me with a non "combined" cross to powerpc64-linux-gnu for both 4.1 and 4.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29780
[Bug tree-optimization/29777] missed optimization: model missing widen_mult* idioms for SSE
--- Comment #1 from ubizjak at gmail dot com 2006-11-09 15:36 --- > The testcases that failed (on assembler error) are two of tests that require > "vect_widen_mult_hi_to_si": > testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c > testsuite/gcc.dg/vect/vect-widen-mult-s16.c > testsuite/gcc.dg/vect/vect-widen-mult-sum.c But these files can be succesfully vectorized using current (gcc version 4.3.0 20061109) version on i686: gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c vect-widen-mult-sum.c:16: note: LOOP VECTORIZED. vect-widen-mult-sum.c:12: note: vectorized 1 loops in function. .L8: movdqu (%eax), %xmm4 movdqu (%ecx,%eax), %xmm2 movdqa %xmm4, %xmm1 movdqa %xmm2, %xmm0 pxor%xmm6, %xmm6 pxor%xmm5, %xmm5 pcmpgtw %xmm2, %xmm6 pcmpgtw %xmm4, %xmm5 punpcklwd %xmm6, %xmm0 punpcklwd %xmm5, %xmm1 movdqa %xmm0, %xmm3 psrldq $4, %xmm0 pmuludq %xmm1, %xmm3 psrldq $4, %xmm1 punpckhwd %xmm6, %xmm2 pmuludq %xmm1, %xmm0 punpckhwd %xmm5, %xmm4 pshufd $8, %xmm3, %xmm3 pshufd $8, %xmm0, %xmm0 punpckldq %xmm0, %xmm3 movd-20(%ebp), %xmm0 psrad %xmm0, %xmm3 movdqa %xmm2, %xmm0 psrldq $4, %xmm2 pmuludq %xmm4, %xmm0 psrldq $4, %xmm4 pmuludq %xmm4, %xmm2 addl$1, %edx paddd %xmm7, %xmm3 pshufd $8, %xmm2, %xmm2 pshufd $8, %xmm0, %xmm7 addl$16, %eax punpckldq %xmm2, %xmm7 movd-20(%ebp), %xmm0 cmpl%edx, %ebx psrad %xmm0, %xmm7 paddd %xmm3, %xmm7 ja .L8 movdqa %xmm7, %xmm1 movl-16(%ebp), %esi psrldq $8, %xmm1 paddd %xmm7, %xmm1 cmpl20(%ebp), %esi movdqa %xmm1, %xmm0 psrldq $4, %xmm0 paddd %xmm1, %xmm0 movd%xmm0, -24(%ebp) movd%xmm0, %edi je .L4 > The missing insns (that should be merged from autovect-branch and debugged): > vec_widen_umult_hi_v8hi > vec_widen_umult_lo_v8hi These patterns _are_ present in gcc version 4.3.0 20061109 (experimental) in sse.md. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #23 from hjl at lucon dot org 2006-11-09 15:47 --- (In reply to comment #20) > > I am playing with some ideas how to fix this, unless I come up with > something > > soon, I will revert the patch (except for the testcase that I would like to > > remain in the testsuite). > > The best I was able to do is the following patch. Virtual operand prunning > removes all the symbols that the SMTs have in common, which causes this PR. > The patch adds artificial "conflict" symbols to all pairs of aliasing SMTs, to > avoid this. Just looking at the dump of the testcase for this PR, it appears > quite expensive (there are a lot of new virtual operands); I will check what > the memory behavior is on larger testcases. > It failed during bootstrap: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-dfa.c: In function âfind_referenced_varsâ: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-dfa.c:99: internal compiler error: in mark_operand_necessary, at tree-ssa-dce.c:261 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [tree-dfa.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug bootstrap/29780] temporary file breaks cross-build
--- Comment #3 from danny dot backx at scarlet dot be 2006-11-09 16:02
---
dannypc: {9} arm-wince-cegcc-gcc -v
Using built-in specs.
Target: arm-wince-cegcc
Configured with:
/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc/configure
--prefix=/usr/ppc --enable-languages=c,c++ --disable-interwork --disable-nls
--enable-checking --disable-multilib --build=i686-pc-linux-gnu
--target=arm-wince-cegcc
Thread model: win32
gcc version 4.1.0
--
danny dot backx at scarlet dot be changed:
What|Removed |Added
CC||danny dot backx at scarlet
||dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29780
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-11-09 16:26 --- Created an attachment (id=12576) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12576&action=view) Amended sched-deps.c patch It occurend to me that the previous patch would not do the right thing when the set is above an existing SCHED_GROUP_P group, with at least one other instruction intervening, while the use is below the group. In that case, all the dependencies of the old SCHED_GROUP_P group need to be transferred to the new group leader. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Attachment #12564|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug c/29782] New: Incorrect inlining failure
GCC sometimes does not inline code claiming the function has grown to large,
while inlining it would have _decreased_ the codesize.
For example, the following block of code, will result in read_time being
inlined:
#include
static inline long long read_time(void) {
long long l;
asm volatile( "rdtsc\n\t"
: "=A" (l)
);
return l;
}
int main()
{
long long l = read_time();
printf("%Ld\n", l);
}
The following block will not inline read_time:
#include
static __attribute__ ((noinline)) long long read_time(void) {
long long l;
asm volatile( "rdtsc\n\t"
: "=A" (l)
);
return l;
}
int main() {
long long l = read_time();
printf("%Ld\n", l);
}
As read_time is really small, its codesize will always be smaller if it gets
inlined. Nonetheless, in some cases the compiler gives a warning that the code
has grown to large, and that it will _disable_ inlining because of this:
"warning: inlining failed in call to read_time: --param large-function-growth
limit reached"
This seems wrong to me as the non-inlined code would be larger then the inlined
code.
Compiling it with:
gcc -c -I. -fomit-frame-pointer -g -Wdeclaration-after-statement -Wall
-Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
-Winline -O3 rdtsc.c
Shows that the inlined version is indeed smaller:
size inlinerdtsc.o
textdata bss dec hex filename
51 0 0 51 33 inlinerdtsc.o
size rdtsc.o
textdata bss dec hex filename
68 0 0 68 44 rdtsc.o
I do not think it is specific to this short block of code, as
the generated assembly shows rdtsc being only 2 bytes long, while
the call instruction by itself already occupies 5 bytes:
Not inlined:
:
0: 0f 31 rdtsc
2: c3 ret
3: 8d b6 00 00 00 00 lea0x0(%esi),%esi
9: 8d bc 27 00 00 00 00lea0x0(%edi),%edi
0010 :
10: 8d 4c 24 04 lea0x4(%esp),%ecx
14: 83 e4 f0and$0xfff0,%esp
17: ff 71 fcpushl 0xfffc(%ecx)
1a: 51 push %ecx
1b: 83 ec 18sub$0x18,%esp
1e: e8 dd ff ff ff call 0
23: c7 04 24 00 00 00 00movl $0x0,(%esp)
2a: 89 44 24 04 mov%eax,0x4(%esp)
2e: 89 54 24 08 mov%edx,0x8(%esp)
32: e8 fc ff ff ff call 33
37: 83 c4 18add$0x18,%esp
3a: 31 c0 xor%eax,%eax
3c: 59 pop%ecx
3d: 8d 61 fclea0xfffc(%ecx),%esp
40: c3 ret
Inlined:
:
0: 8d 4c 24 04 lea0x4(%esp),%ecx
4: 83 e4 f0and$0xfff0,%esp
7: ff 71 fcpushl 0xfffc(%ecx)
a: 51 push %ecx
b: 83 ec 18sub$0x18,%esp
e: 0f 31 rdtsc
10: 89 44 24 04 mov%eax,0x4(%esp)
14: 89 54 24 08 mov%edx,0x8(%esp)
18: c7 04 24 00 00 00 00movl $0x0,(%esp)
1f: e8 fc ff ff ff call 20
24: 83 c4 18add$0x18,%esp
27: 31 c0 xor%eax,%eax
29: 59 pop%ecx
2a: 8d 61 fclea0xfffc(%ecx),%esp
2d: c3 ret
Does GCC just disable all inlining as soon as a certain limit in codesize is
reached? Or does it actually try to determine whether inlining will increase or
decrease the codesize? If so, is an heuristic used or an exact calculation (if
possible)? If an heuristic is used, what is the heuristic?
Thanks for any reply! :)
System info:
* Ubuntu Edgy Eft 6.10
* Linux issaris 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686
GNU/Linux
* Intel(R) Pentium(R) 4 CPU 3.20GHz
* Compiler:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
With friendly regards,
Takis
--
Summary: Incorrect inlining failure
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: takis at issaris dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
h
[Bug c/29782] Incorrect inlining failure
--- Comment #1 from takis at issaris dot org 2006-11-09 16:31 --- Created an attachment (id=12577) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12577&action=view) Call a function and recommend to inline it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
[Bug c/29782] Incorrect inlining failure
--- Comment #2 from takis at issaris dot org 2006-11-09 16:32 --- Created an attachment (id=12578) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12578&action=view) Call a function and disallow inlining it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-11-09 16:33 --- (In reply to comment #8) > I don't see ICEs for the tls tests on my sh-elf build with > your patches in #6 and #7. Does the new patch in #7 fix them? Yes, but I am still seeing these changes: > FAIL: g++.dg/opt/reg-stack2.C (internal compiler error) > FAIL: g++.dg/opt/reg-stack2.C (test for excess errors) 189a189,190 > FAIL: g++.dg/opt/reg-stack2.C (internal compiler error) > FAIL: g++.dg/opt/reg-stack2.C (test for excess errors) 202d202 < FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug middle-end/29782] Incorrect inlining failure
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-09 17:10 --- It has a heuristic to tell the result in code-size difference. Of course no heuristic is perfect - see tree-inline.c:estimate_num_insns(). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #24 from dberlin at gcc dot gnu dot org 2006-11-09 17:22 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc On 11/9/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote on 11/09/06 10:05: > > > One thing i'm going to try later is to try to partition all the > > stores/load statements and figure out how many symbols it takes to > > represent the results exactly (IE one symbol for each set of > > statements that must interfere with each other, where each statement > > can be in multiple partitions). > > > This is what I'm doing in memory SSA. More details later this week > after I'm done testing and such. The difference is that partitioning is > embedded in the actual SSA form and the partitioning heuristic can be > changed independently of the renamer. This will let us play with a > slider-style throttling for precision/compile-time. > Right, but the difference is, In the scheme i propose, you'd never have overlapping live ranges of vuse/vdefs, and in mem-ssa, you do. IE we wouldn't run into all the problems mem-ssa is going to bring in this regard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug middle-end/28436] accessing an element via a "pointer" on a vector does not cause vec_extract to be used
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-09 17:24 --- Testing a fix for this one, though it only does the simple *(int*)&vector_int_var case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28436
Re: [Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
Can you try the attached and let me know if it fixes it? fordanglin.diff Description: Binary data
[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-11-09 17:24 --- Subject: Re: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes Can you try the attached and let me know if it fixes it? --- Comment #12 from dberlin at gcc dot gnu dot org 2006-11-09 17:24 --- Created an attachment (id=12579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12579&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-11-09 17:28 --- Created an attachment (id=12580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12580&action=view) current software floating point patch I am testing this patch now. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Attachment #12563|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug middle-end/29782] Incorrect inlining failure
--- Comment #4 from takis at issaris dot org 2006-11-09 17:28 --- (In reply to comment #3) > It has a heuristic to tell the result in code-size difference. Of course no > heuristic is perfect - see tree-inline.c:estimate_num_insns(). Ofcourse! Thanks for your reply! So, I guess that if I were to move ASM_EXPR to the list of zero cost cases, GCC would always inline my code. I'll see if this works. Thanks again! :) Still, I think it is weird I'm seeing this behavior, as with my untrained eyes, it seems as if inline assembly would only get 1 assigned as cost, while a function call probably costs 4+something (I guess from estimate_move_cost() although it can also return another value of which I am currently not capable of determining the value). This would mean inlining of functions containing only inline assembly blocks would always succeed, right? Hmm... Unless the else in estimate_move_cost() can return 0 or 1 in some cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
[Bug libfortran/29784] New: Converting logical <-> integer in IO
Currently, gfortran supports
integer = logical
and
logical = integer
with a default warning
"Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1)"
However, some compilers also support:
print '(i0)', logical
gfortran currently gives:
"Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got
LOGICAL"
Other compilers:
- g95 and NAG f95 give always a run-time error
- Intel supports it (no warning; .true. is -1, .false.; int even = false, int
odd = true); printing logical = 10, shows "10".
- sunf95: Assignment not supported (compile-time error), but '(i0)' is
supported ("1" and "0", 0 = .false., 0 /= .true.)
- At least IO is also supported by g77, IBM xlf and HP/UX fort77
cf. http://gcc.gnu.org/ml/fortran/2006-11/msg00274.html
Expected:
(a) We explicitly state that this is not supported for IO.
(b) We support '(i0)' for logical and document this also in "7.11 Implicitly
interconvert LOGICAL and INTEGER" and continue to give for -std=f95/f2003 a
run-time error, i.e. changing in io/transfer.c's formatted_transfer_scalar
along these lines:
case FMT_I: [...]
if (require_type (dtp, BT_INTEGER, type, f))
- return;
+ {
+if (compile_options.allow_std < GFC_STD_GNU
+ && require_type (dtp, BT_LOGICAL, type, f))
+ return;
+ }
Maybe one could also use GFC_STD_LEGACY instead of GFC_STD_GNU.
I don't know whether one needs also to change something for READing or whether
one wants to support reading.
--
Summary: Converting logical <-> integer in IO
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
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=29784
[Bug middle-end/29782] Incorrect inlining failure
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-09 17:31 --- Can you give your full testcase as right now the above testcases don't show what your code looks like and why we are reaching the large-function-growth limit. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29782
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #18 from janis187 at us dot ibm dot com 2006-11-09 17:34 --- Subject: Re: bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc On Thu, Nov 09, 2006 at 10:15:24AM -, irar at il dot ibm dot com wrote: > However, the failure in comment #3 still occurs in the later revisions. So, I > am going to hunt for a later patch that broke bootstrap with vectorization > (applying the above patch). I can do that with my regression hunt setup, if you'd like; it's set up to allow adding patches for each new version tested. Janis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-11-09 17:37 --- (In reply to comment #8) > I don't see ICEs for the tls tests on my sh-elf build with > your patches in #6 and #7. Does the new patch in #7 fix them? > > I've confirmed that the trunk bootstraps successfully with > the patch in #4 and a one-liner to suppress a bogus compile > time warning. Should I send it to the list as a workaround > this PR? The problem looks like another instance of the scheduler bug. Could you try the original cbranchdi_i pattern with the patch from comment #9? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #25 from dnovillo at redhat dot com 2006-11-09 17:38 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc Daniel Berlin wrote on 11/09/06 12:22: > Right, but the difference is, In the scheme i propose, you'd never > have overlapping live ranges of vuse/vdefs, and in mem-ssa, you do. > IE we wouldn't run into all the problems mem-ssa is going to bring in > this regard. No, that's not right. Overlapping live-ranges are not a problem until you hit a PHI node. That's where currently mem-ssa is having difficulties with. We can use those static partitions at key points during SSA renaming. Since the partitions are completely unrelated to the renamer, we can experiment with different partitioning schemes. It's actually even possible to arrive to a perfect partitioning scheme that doesn't introduce false positive dependencies. More details to follow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #26 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-11-09 18:03 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc > > Right, but the difference is, In the scheme i propose, you'd never > > have overlapping live ranges of vuse/vdefs, and in mem-ssa, you do. > > IE we wouldn't run into all the problems mem-ssa is going to bring in > > this regard. > > No, that's not right. Overlapping live-ranges are not a problem until > you hit a PHI node. That's where currently mem-ssa is having > difficulties with. well, in any case, Daniel's proposal has advantage that it is much less intrusive than mem-ssa -- does not need to change ssa renaming at all, probably needs much less changes to operand scanning, and does not need any changes to optimizations that assume vops are in FUD form (i.e., that the life ranges of vops do not overlap). If he could create (or help someone create) a working prototype in reasonable time (few weeks?), I would very much like to see it compared with mem-ssa before mem-ssa branch is merged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
Re: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
"some VAR_DECL or structure that has a name" (like our memory tags
do). A symbol is *not* a real variable that occurred in the user
program. When I say "varaible" i mean a variable that occurred in the
user program.
The real problem with our alias system in terms of precision, and
often in terms of number of useless vops, is that we are trying to use
real, existing, variables, to approximate the portions of the heap a
statement accesses.
When things access portions of the heap we can't see (nonlocal
variables), we fall down badly in terms of precision because we can
eliminate every single local variable as an alias, and need to then
just say it accesses "some nonlocal variable". This causes precision
problems because it means that statements accessing nonlocal variables
that we can *prove* don't interfere, still currently share a VUSE
between them.
We also have useless vops whenever we have points-to sets that
intersect between all statements that interfere, because we end up
adding aliases for you can eliminate the members of the alias set
We also currently rely on operand-scan time pruning, which is very ugly.
There is a way to get the minimal number of vuses/vdefs necessary to
represent completely precise (in terms of info we have) aliasing,
while still being able to degrade the precision gracefully in order to
enable the vuses/vdefs necessary to go down
The scheme i propose *never* has overlapping live ranges of the
individual symbols, even though the symbols may represent pieces of
the same heap.
In other words, you can rely on the fact that once an individual
symbol has a new version, there will never be a vuse of an old version
of that symbol.
The current vdef/vuse scheme consists of creating memory tags to
represent portions of the heap. When a memory tag has aliases, we use
it's alias list to generate virtual operands. When a memory tag does
not have aliases, we generate a virtual operand of the base symbol.
The basic idea in the new scheme is to never have a list of aliases
for a symbol representing portions of the heap. The symbols
representing portions of the heap are themselves always the target of
a vuse/vdef. The aliases they represent is immaterial (though we can
keep a list if something wants it).
This enables us to have a smaller number of vops, and have something
else generate the set of symbols in a precise manner, rather than have
things like the operand scanner try to post process it.
The symbols are also attached to the load/store statements, and not to
the variables.
The operand renamer only has to add vuses/vdefs for all the symbols
attached to a statement, and it is done.
In the simplest, dumb, non-precise version of this scheme, this means
you only have one symbol, called "MEM", and generate vuse/vdefs
linking every load/store together.
In the absolute most-precise version of this scheme, you partition the
loads/store conflicts in statements into symbols that represent
statement conflictingness.
In a completely naive, O(N^3) version, the following algorithm will
work and generate completely precise results:
Collect all loads and stores into a list (lslist)
for each statement in lslist (x):
for each statement in lslist (y):
if x conflicts with y:
if there is no partition for x, y, create a new one containing x and y.
otherwise
for every partition y belongs to:
if all members of this partition have memory access that
conflicts with x:
add x to this partition
otherwise
create a new partition containing all members of the
partition except the ones x does not conflict with.
add x to this partition
This is a very very slow way to do it, but it should be clear (there
are much much much faster ways to do this).
Basically, a single load/store statement can belong to multiple
partitions. All members of a given partition conflict with each
other.
given the following set of memory accesses statements:
a, b, c, d
where:
a conflicts with b and c
b conflicts with c and d
c conflicts with a and b
d conflicts with a and c
you will end up with 3 partitions:
part1: {a, b, c}
part2: {b, c, d}
part3: {d, a, c}
statement c will conflict with every member of partition 1 and thus
get partition 1, rather than a new partition.
You now create symbols for each partition, and for each statement in
the partition, add the symbol to it's list.
Thus, in the above example we get
statement a - symbols: MEM.PART1, MEM.PART3
statement b - symbols: MEM.PART1, MEM.PART2
statement c - symbols: MEM.PART1, MEM.PART2, MEM.PART3
statement d - symbols MEM.PART2, MEM.PART3
As mentioned before, the operand renamer simply adds a vdef/vuse for
each symbol in the statement list.
Note that this is the minimal number of symbols necessary to precisely
represent the conflicting accesses.
If the number of partitions
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #27 from dberlin at gcc dot gnu dot org 2006-11-09 18:21
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
"some VAR_DECL or structure that has a name" (like our memory tags
do). A symbol is *not* a real variable that occurred in the user
program. When I say "varaible" i mean a variable that occurred in the
user program.
The real problem with our alias system in terms of precision, and
often in terms of number of useless vops, is that we are trying to use
real, existing, variables, to approximate the portions of the heap a
statement accesses.
When things access portions of the heap we can't see (nonlocal
variables), we fall down badly in terms of precision because we can
eliminate every single local variable as an alias, and need to then
just say it accesses "some nonlocal variable". This causes precision
problems because it means that statements accessing nonlocal variables
that we can *prove* don't interfere, still currently share a VUSE
between them.
We also have useless vops whenever we have points-to sets that
intersect between all statements that interfere, because we end up
adding aliases for you can eliminate the members of the alias set
We also currently rely on operand-scan time pruning, which is very ugly.
There is a way to get the minimal number of vuses/vdefs necessary to
represent completely precise (in terms of info we have) aliasing,
while still being able to degrade the precision gracefully in order to
enable the vuses/vdefs necessary to go down
The scheme i propose *never* has overlapping live ranges of the
individual symbols, even though the symbols may represent pieces of
the same heap.
In other words, you can rely on the fact that once an individual
symbol has a new version, there will never be a vuse of an old version
of that symbol.
The current vdef/vuse scheme consists of creating memory tags to
represent portions of the heap. When a memory tag has aliases, we use
it's alias list to generate virtual operands. When a memory tag does
not have aliases, we generate a virtual operand of the base symbol.
The basic idea in the new scheme is to never have a list of aliases
for a symbol representing portions of the heap. The symbols
representing portions of the heap are themselves always the target of
a vuse/vdef. The aliases they represent is immaterial (though we can
keep a list if something wants it).
This enables us to have a smaller number of vops, and have something
else generate the set of symbols in a precise manner, rather than have
things like the operand scanner try to post process it.
The symbols are also attached to the load/store statements, and not to
the variables.
The operand renamer only has to add vuses/vdefs for all the symbols
attached to a statement, and it is done.
In the simplest, dumb, non-precise version of this scheme, this means
you only have one symbol, called "MEM", and generate vuse/vdefs
linking every load/store together.
In the absolute most-precise version of this scheme, you partition the
loads/store conflicts in statements into symbols that represent
statement conflictingness.
In a completely naive, O(N^3) version, the following algorithm will
work and generate completely precise results:
Collect all loads and stores into a list (lslist)
for each statement in lslist (x):
for each statement in lslist (y):
if x conflicts with y:
if there is no partition for x, y, create a new one containing x and y.
otherwise
for every partition y belongs to:
if all members of this partition have memory access that
conflicts with x:
add x to this partition
otherwise
create a new partition containing all members of the
partition except the ones x does not conflict with.
add x to this partition
This is a very very slow way to do it, but it should be clear (there
are much much much faster ways to do this).
Basically, a single load/store statement can belong to multiple
partitions. All members of a given partition conflict with each
other.
given the following set of memory accesses statements:
a, b, c, d
where:
a conflicts with b and c
b conflicts with c and d
c conflicts with a and b
d conflicts with a and c
you will end up with 3 partitions:
part1: {a, b, c}
part2: {b, c, d}
part3: {d, a, c}
statement c will conflict with every member of partition 1 and thus
get partition 1, rather than a new partition.
You now create symbols for each partition, and for each statement in
the partition, add the symbol to it's list.
Thus, in the above example we get
statement a - symbols: MEM.PART1, MEM.PART3
statement b - symbols: MEM.PART1, MEM.PART2
statement c - symbols: MEM.PART1, MEM.PART2, MEM.PART3
statement d - symbols MEM.PART2, MEM.PART3
As mentioned before, the operand renamer simply adds a vdef/vuse for
each symbol in
[Bug fortran/29699] ICE in trans-decl.c
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-09 18:42 --- Subject: Bug 29699 Author: pault Date: Thu Nov 9 18:42:28 2006 New Revision: 118624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118624 Log: 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29699 * trans-array.c (structure_alloc_comps): Detect pointers to arrays and use indirect reference to declaration. * resolve.c (resolve_fl_variable): Tidy up condition. (resolve_symbol): The same and only add initialization code if the symbol is referenced. * trans-decl.c (gfc_trans_deferred_vars): Call gfc_trans_ deferred_array before gfc_trans_auto_array_allocation. PR fortran/21730 * symbol.c (check_done): Remove. (gfc_add_attribute): Remove reference to check_done and remove the argument attr_intent. (gfc_add_allocatable, gfc_add_dimension, gfc_add_external, gfc_add_intrinsic, gfc_add_optional, gfc_add_pointer, gfc_add_cray_pointer, gfc_add_cray_pointee, gfc_add_result, gfc_add_target, gfc_add_in_common, gfc_add_elemental, gfc_add_pure, gfc_add_recursive, gfc_add_procedure, gfc_add_type): Remove references to check_done. * decl.c (attr_decl1): Eliminate third argument in call to gfc_add_attribute. * gfortran.h : Change prototype for gfc_add_attribute. 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29699 * gfortran.dg/alloc_comp_auto_array_1.f90: New test. PR fortran/21730 * gfortran.dg/change_symbol_attributes_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_1.f90 trunk/gcc/testsuite/gfortran.dg/change_symbol_attributes_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29699
[Bug fortran/21730] [4.0 only] Character length incorrect.
--- Comment #16 from pault at gcc dot gnu dot org 2006-11-09 18:42 --- Subject: Bug 21730 Author: pault Date: Thu Nov 9 18:42:28 2006 New Revision: 118624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118624 Log: 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29699 * trans-array.c (structure_alloc_comps): Detect pointers to arrays and use indirect reference to declaration. * resolve.c (resolve_fl_variable): Tidy up condition. (resolve_symbol): The same and only add initialization code if the symbol is referenced. * trans-decl.c (gfc_trans_deferred_vars): Call gfc_trans_ deferred_array before gfc_trans_auto_array_allocation. PR fortran/21730 * symbol.c (check_done): Remove. (gfc_add_attribute): Remove reference to check_done and remove the argument attr_intent. (gfc_add_allocatable, gfc_add_dimension, gfc_add_external, gfc_add_intrinsic, gfc_add_optional, gfc_add_pointer, gfc_add_cray_pointer, gfc_add_cray_pointee, gfc_add_result, gfc_add_target, gfc_add_in_common, gfc_add_elemental, gfc_add_pure, gfc_add_recursive, gfc_add_procedure, gfc_add_type): Remove references to check_done. * decl.c (attr_decl1): Eliminate third argument in call to gfc_add_attribute. * gfortran.h : Change prototype for gfc_add_attribute. 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29699 * gfortran.dg/alloc_comp_auto_array_1.f90: New test. PR fortran/21730 * gfortran.dg/change_symbol_attributes_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_1.f90 trunk/gcc/testsuite/gfortran.dg/change_symbol_attributes_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/29785] New: Fortran 2003: POINTER Rank Remapping
POINTER Rank Remapping (From http://www.fortran.bcs.org/forum2002/f2000dme.htm) Motivation: ability to have pointers to diagonals of matrices. REAL,ALLOCATABLE,TARGET :: base_array(:) REAL,POINTER :: matrix(:,:) REAL,POINTER :: diagonal(:) ... ALLOCATE(base_array(n*n)) matrix(1:n,1:n) => base_array ! rank remapping diagonal => base_array(::n+1) Notes: * The base array must be rank one, to ensure that the remapping is a simple linear transformation. * Both lower bound and upper bound must be specified for each dimension. Fortran 2003 standard, see "7.4.2.1 Data pointer assignment": "R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] => data-target or data-pointer-object (bounds-remapping-list ) => data-target or proc-pointer-object => proc-target C718 (R735) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data pointer-object. C719 (R735) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the rank of data-pointer-object. C720 (R735) If bounds-remapping-list is specified, data-target shall have rank one; otherwise, the ranks of data-pointer-object and data-target shall be the same." and "7.4.2.1 Data pointer assignment": "If bounds-remapping-list is specified, data-target shall not be a disassociated or undefined pointer, and the size of data-target shall not be less than the size of data-pointer-object. The elements of the target of data-pointer-object, in array element order (6.2.2.2), are the first SIZE(data-pointer-object) elements of data-target." -- Summary: Fortran 2003: POINTER Rank Remapping Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-09 18:48:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #28 from dnovillo at gcc dot gnu dot org 2006-11-09 19:15 --- (In reply to comment #26) > I would very much like to see it compared with mem-ssa before mem-ssa > branch is merged. > Notice that the two approaches do not negate each other. Dan's proposal is a smarter partitioning than what the current alias grouping mechanism tries to do. We can actually have memory SSA on top of Dan's partitioning scheme. Memory SSA will use that partitioning scheme when placing memory PHI nodes. The two approaches are orthogonal. Memory SSA simply adds a new degree of factoring that gives you sparser UD chains. It also gives you exactly one name per store, without reducing precision. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug middle-end/29726] [4.2/4.3 regression] invalid folding of ((X >> C1) & C2) != 0 or "M-x is undefined" in emacs
--- Comment #4 from sayle at gcc dot gnu dot org 2006-11-09 19:24 --- Subject: Bug 29726 Author: sayle Date: Thu Nov 9 19:24:32 2006 New Revision: 118625 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118625 Log: 2006-11-09 Serge Belyshev <[EMAIL PROTECTED]> PR middle-end/29726 * fold-const.c (fold_binary) : Fix typo in variable name. * gcc.dg/fold-eqandshift-1.c (test5): Uncomment function. (test6): Ditto. (dg-final): Add scan-tree-dump-times patterns for test5 and test6. * gcc.dg/fold-eqandshift-3.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/fold-eqandshift-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/fold-eqandshift-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29726
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #29 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-11-09 19:41 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc > > I would very much like to see it compared with mem-ssa before mem-ssa > > branch is merged. > > > Notice that the two approaches do not negate each other. Dan's proposal is a > smarter partitioning than what the current alias grouping mechanism tries to > do. We can actually have memory SSA on top of Dan's partitioning scheme. > Memory SSA will use that partitioning scheme when placing memory PHI nodes. > > The two approaches are orthogonal. Memory SSA simply adds a new degree of > factoring that gives you sparser UD chains. It also gives you exactly one > name > per store, without reducing precision. nevertheless, it is not obvious to me whether using mem-ssa over Daniel's proposal would bring any significant gains, which I would like to have verified before we introduce milion new bugs with mem-ssa (nothing personal, it simply is too large and too intrusive change not to bring any). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #30 from dnovillo at gcc dot gnu dot org 2006-11-09 19:48 --- (In reply to comment #29) > nevertheless, it is not obvious to me whether using mem-ssa over Daniel's > proposal would bring any significant gains, which I would like to have > Of course. If you are interested in the compile time benefits of a partitioning scheme, you can actually try the one we already have by forcing alias grouping more aggressively (--param max-aliased-vops). The current grouping is very dumb and will create tons of false positives. Daniel's approach will try to reduce false positives while bringing down the number of virtual operators per memory statement. Memory SSA brings down the number of virtual operators to exactly one per statement. > verified before we introduce milion new bugs with mem-ssa (nothing > personal, it simply is too large and too intrusive change not to bring > any). > Intrusive? Well, the only pass that was wired to the previous virtual operator scheme was PRE. DSE is also wired but to a lesser extent. No other optimization had to be changed for mem-ssa. It's obviously intrusive in the renamer, but that's it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug fortran/29786] New: [4.1/4.2/4.3 Regression] rejects equivalence
$ cat equiv.hm.f INTEGER i PARAMETER (i = 55) INTEGER o INTEGER NUNITS(i) equivalence (o,nunits(16)) data o/16/ data nunits(18)/18/ end $ gfortran-4.3-HEAD -c -o /dev/null equiv.hm.f equiv.hm.f:5: equivalence (o,nunits(16)) 1 Error: Initialized objects 'o' and 'nunits' cannot both be in the EQUIVALENCE statement at (1) Works fine with g77-3.4.6 -- Summary: [4.1/4.2/4.3 Regression] rejects equivalence Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug middle-end/29726] [4.2 regression] invalid folding of ((X >> C1) & C2) != 0 or "M-x is undefined" in emacs
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2006-11-09 19:51 --- fixed on trunk. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Known to work||4.3.0 Summary|[4.2/4.3 regression] invalid|[4.2 regression] invalid |folding of ((X >> C1) & C2) |folding of ((X >> C1) & C2) |!= 0 or "M-x is undefined" |!= 0 or "M-x is undefined" |in emacs|in emacs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29726
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-09 20:04 --- Dorit, Nothing stands out in the gfortran patches in that interval, although I am not sure what I am looking for. I base my remark on the fact that none of the patches between 10/27 and 10/31 would appear to touch that subroutine. The code generated for vect-3.f90 looks OK, so I would have to suppose that the problem has arisen further downstream. Regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-09 20:14 --- Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-09 20:14:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/29744] [Regression] Type renaming crashes gfortran with excessive memory usage
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-09 20:22 --- Subject: Bug 29744 Author: pault Date: Thu Nov 9 20:22:19 2006 New Revision: 118627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118627 Log: 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29744 * trans-types.c (gfc_get_derived_type): Ensure that the proc_name namespace is not the same as the owner namespace and that identical derived types in the same namespace share the same backend_decl. 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29744 * gfortran.dg/used_types_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29744
[Bug tree-optimization/29777] missed optimization: model missing widen_mult* idioms for SSE
--- Comment #2 from dorit at il dot ibm dot com 2006-11-09 20:26 --- > But these files can be succesfully vectorized using current (gcc version 4.3.0 > 20061109) version on i686: > gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c > vect-widen-mult-sum.c:16: note: LOOP VECTORIZED. > vect-widen-mult-sum.c:12: note: vectorized 1 loops in function. Probably because the i386 port models the "vect_unpack" and "vect_int_mult" idioms (see target-supports.exp:check_effective_target_vect_widen_mult_hi_to_si()): i.e., instead of recognizing it's a widening multiplication and vectorizing it as such, it's vectorized by first unpacking (widening) the shorts to ints, and then doing int multiplication, which is probably less efficient. Sorry for the unclarity > > The missing insns (that should be merged from autovect-branch and debugged): > > vec_widen_umult_hi_v8hi > > vec_widen_umult_lo_v8hi > These patterns _are_ present in gcc version 4.3.0 20061109 (experimental) in > sse.md. I'm sorry - I meant vec_widen_smult_hi_v8hi and vec_widen_smult_lo_v8hi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-11-09 20:43 --- Created an attachment (id=12581) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12581&action=view) patch for reading and backspace Here's the next installment of the patch, which seems to work OK for backspace, too. Some more testing is still required. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #12550|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug c++/29787] New: std::vector can access negative value (std runtime bug?)
When you accessing vector element by negative index, nothing happens (but as i
think, the runtime error should happened). The glibc (double free()) happens
when destructor of the vector object called (at the end of the program). While
you haven't reached the vector object destructor, you can work normally and no
effect happens(? May be strange random SegFaults in random time).
Here is example code of the problem:
#include
#include
#include
int main(int argc, char argv[]){
std::vector v;
for(int j = 0; j <= 10; j++){
int *i = new int;
*i = 10;
v.push_back(*i);
}
int j = -1;
v[j] = 11;
std::cout << "." << v[j] << std::endl;
printf("v[-1]: %d\n", v[j]);
v.clear();
std::cout << "Clearing finished... Empty: " << v.empty() << std::endl;
//many operations
// <- he you can MADE MANY operations (program may work for hours,
// without any bad effects)
std::cout << "All is still ok..." << std::endl;
}
Compiled it with:
g++ bug.cc --debug -Wall -o bug
./bug
.11
v[-1]: 11
Clearing finished... Empty: 1
All is still ok...
*** glibc detected *** ./bug: double free or corruption (out):
0x00503160 ***
=== Backtrace: =
/lib/libc.so.6[0x2b077879a7ec]
/lib/libc.so.6(__libc_free+0x76)[0x2b077879b356]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6(_ZdlPv+0xe)[0x2b077838b04e]
./bug[0x401965]
./bug[0x401772]
./bug[0x4011a2]
./bug(__gxx_personality_v0+0x4d4)[0x401014]
./bug(__gxx_personality_v0+0x38e)[0x400ece]
/lib/libc.so.6(__libc_start_main+0xf6)[0x2b077874e136]
./bug(__gxx_personality_v0+0x69)[0x400ba9]
=== Memory map:
..skipped.
With gdb, i see that bug happens is in line 83 of new_allocator.h:
"
// __p is not permitted to be a null pointer.
void
deallocate(pointer __p, size_type)
{ ::operator delete(__p); }
"
Gcc compiled with: --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g+
+-v4
--host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu
--disable-altivec
--enable-nls
--without-included-gettext
--with-system-zlib
--disable-checking
--disable-werror
--disable-libunwind-exceptions
--enable-multilib
--disable-libmudflap
--disable-libssp
--disable-libgcj
--enable-languages=c,c++,fortran
--enable-shared
--enable-threads=posix
--enable-__cxa_atexit
--enable-clocale=gnu
CFLAGS="-march=k8 -pipe -O2"
CXXFLAGS="-march=k8 -pipe -O2"
Same problem also exists on gcc 3.4.6 under cygwin.
Is it a bug or feature? On MS VC++ compiler v[j] line generates runtime
exception immediately.
Sorry for my *bad* English.
--
Summary: std::vector can access negative value (std runtime bug?)
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: key at timeold dot ru
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29787
[Bug fortran/29788] New: [Optimization] ICE in var_ann, at tree-flow-inline.h:130
Hi, the attached code compiles at -O0 but crashes gfortran at -O or higher: gfcbug43.f90: In function 'try_fit': gfcbug43.f90:43: internal compiler error: in var_ann, at tree-flow-inline.h:130 (I tried to do my best, but I haven't been able to reduce the example further.) Cheers, -ha -- Summary: [Optimization] ICE in var_ann, at tree-flow-inline.h:130 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
[Bug fortran/29744] [Regression] Type renaming crashes gfortran with excessive memory usage
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-09 21:26 --- Subject: Bug 29744 Author: pault Date: Thu Nov 9 21:26:14 2006 New Revision: 118629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118629 Log: 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29744 * trans-types.c (gfc_get_derived_type): Ensure that the proc_name namespace is not the same as the owner namespace and that identical derived types in the same namespace share the same backend_decl. 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29744 * gfortran.dg/used_types_12.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_types_12.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29744
[Bug fortran/29788] [Optimization] ICE in var_ann, at tree-flow-inline.h:130
--- Comment #1 from anlauf at gmx dot de 2006-11-09 21:27 --- Created an attachment (id=12582) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12582&action=view) Sample crashing gfortran at -O -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
Re: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
Memory SSA brings down the number of virtual operators to exactly one per statement. However, it does so in a way that makes the traditional things that actually want to do cool memory optimizations, harder. I'm still on the fence over whether it's a good idea or not. > verified before we introduce milion new bugs with mem-ssa (nothing > personal, it simply is too large and too intrusive change not to bring > any). > Intrusive? Well, the only pass that was wired to the previous virtual operator scheme was PRE. DSE is also wired but to a lesser extent. No other optimization had to be changed for mem-ssa. It's obviously intrusive in the renamer, but that's it. Uh, LIM and store sinking are too. Roughly all of our memory optimizations are. The basic problem is in mem-ssa that vdefs and vuses don't accurately reflect what symbols are being defined and used anymore. They represent the factoring of a use and definition of a whole bunch of symbols. Things like PRE and DSE break not because they are "wired to the previous virtual operator scheme" so much, but because they rely on the virtual use/def chains accurately representing where a symbol representing a memory access dies. In mem-ssa, you have VDEF's of the same symbol all over the place. The changes i have to make to PRE (and to the other things) to account for this is actually to rebuild the non-mem-ssa-factored (IE the current factored) form out of the chains by seeing what symbols they really affect. This is going to be expensive, and IMHO, is what almost all of our SSA memory optimizations are going to have to do. So while mem-ssa doesn't affect *precision*, it does affect how you can use the chains in a very significant way. For at least all the opts i see us doing, it makes them more or less useless without doing things (like reexpanding them) first. Because this is true, I'm not sure it's a good idea at all, which is why i'm still on the fence.
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #31 from dberlin at gcc dot gnu dot org 2006-11-09 21:28 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc > > Memory SSA brings down the number of virtual operators to exactly one per > statement. However, it does so in a way that makes the traditional things that actually want to do cool memory optimizations, harder. I'm still on the fence over whether it's a good idea or not. > > > > verified before we introduce milion new bugs with mem-ssa (nothing > > personal, it simply is too large and too intrusive change not to bring > > any). > > > Intrusive? Well, the only pass that was wired to the previous virtual > operator > scheme was PRE. DSE is also wired but to a lesser extent. No other > optimization had to be changed for mem-ssa. It's obviously intrusive in the > renamer, but that's it. Uh, LIM and store sinking are too. Roughly all of our memory optimizations are. The basic problem is in mem-ssa that vdefs and vuses don't accurately reflect what symbols are being defined and used anymore. They represent the factoring of a use and definition of a whole bunch of symbols. Things like PRE and DSE break not because they are "wired to the previous virtual operator scheme" so much, but because they rely on the virtual use/def chains accurately representing where a symbol representing a memory access dies. In mem-ssa, you have VDEF's of the same symbol all over the place. The changes i have to make to PRE (and to the other things) to account for this is actually to rebuild the non-mem-ssa-factored (IE the current factored) form out of the chains by seeing what symbols they really affect. This is going to be expensive, and IMHO, is what almost all of our SSA memory optimizations are going to have to do. So while mem-ssa doesn't affect *precision*, it does affect how you can use the chains in a very significant way. For at least all the opts i see us doing, it makes them more or less useless without doing things (like reexpanding them) first. Because this is true, I'm not sure it's a good idea at all, which is why i'm still on the fence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
Re: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
In mem-ssa, you have VDEF's of the same symbol all over the place. version of a symbol
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #32 from dberlin at gcc dot gnu dot org 2006-11-09 21:29 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc > In mem-ssa, you have VDEF's of the > same symbol all over the place. > version of a symbol -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #33 from dnovillo at redhat dot com 2006-11-09 21:48 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc dberlin at dberlin dot org wrote on 11/09/06 16:28: > Uh, LIM and store sinking are too. Roughly all of our memory > optimizations are. > They are? Really? Can you show me where exactly? > The changes i have to make to PRE (and to the other things) to > account for this is actually to rebuild the non-mem-ssa-factored (IE > the current factored) form out of the chains by seeing what symbols > they really affect. > OK, so how come you were so positive about the new interface? I need to understand what was the great difficulty you ran into that made you change your mind. I need to see a specific example. See, the UD chains you get in mem-ssa are neither incomplete nor wrong. The symbols affected are right there in plain sight, so there is no loss of any information. > For at least all the opts i see us doing, it makes them more or less > useless without doing things (like reexpanding them) first. Because > this is true, I'm not sure it's a good idea at all, which is why i'm > still on the fence. > But you still haven't *shown* me where the hardness or slowness comes in. Granted, the work is still unfinished so we can't really do actual measurements. But I need to understand where the difficulties will be so that I can accomodate the infrastructure. It's obviously not my intent to make things harder to use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug c++/29773] name mangling for nested functions is wrong
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-11-09 21:49 --- There is a contradiction here in the ABI. The formal syntax in the ABI says that a cannot appear inside a , but the example I mentioned is trying to show that it does. However, the formal syntax in the ABI also says that a does not end with a type specification, and if that was true, you couldn't use it for a nested function, because you need to include their argument types to allow overloading. Possibly this is just bug(s) in the ABI, and GCC is doing the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29773
[Bug tree-optimization/29789] New: Missed optimization in libquantum
In SPEC 2k6 libquantum we can find the following (simplified) hot loop
void
quantum_toffoli(int control1, int control2, int target, unsigned long *state,
int size)
{
int i;
for(i=0; i> foo) & 1. Both require
two operations, but the latter can be done in one less insn
on machines that have only two-operand insns or on which a
constant cannot be the first operand. */
which causes the bit-tests to be written with a not loop-invariant shift.
--
Summary: Missed optimization in libquantum
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 15357,26163
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug tree-optimization/29789] Missed optimization in libquantum
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-09 22:07 --- If the fold transformation is disabled we can force lim to move the shifts out of the loop by specifying --param lim-expensive=1 (it considers the shifts being of cost one). The default of the param is 20 though. PRE thinks the shifts are loop induction variables, so it doesn't move them out of the loop. With the above "fixes" we get .L4: movl(%edi,%ecx,4), %edx testl %edx, %ebx je .L5 testl %edx, %esi je .L5 xorl%eax, %edx movl%edx, (%edi,%ecx,4) .p2align 4,,7 .L5: addl$1, %ecx cmpl24(%ebp), %ecx jne .L4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #2 from sergstesh at yahoo dot com 2006-11-09 22:30 --- After using 'make -k check' I see much more failures that reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760 , i.e. in my environment gcc-4.1.1 test suite produces much more failures than gcc-3.4.6 test suite. Here are some quick stats: " /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1> grep 'of unexpected failures' make_-k_check.log # of unexpected failures5 # of unexpected failures1 # of unexpected failures1 # of unexpected failures150 "; " [46] 0:23 [EMAIL PROTECTED]:/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1> grep FAIL: make_-k_check.log FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vectorized 1 loops 2 FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check FAIL: libmudflap.c/fail1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail16-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail17-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail18-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail19-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail2-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail20-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail21-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail22-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail23-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail25-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail26-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail27-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail28-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail29-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail3-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail30-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail31-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail32-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail33-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail34-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail35-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail36-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail37-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail38-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail39-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail4-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail40-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail5-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail6-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail7-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail8-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail9-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/heap-scalestress.c (-static) (test for excess errors) FAIL: libmudflap.c/hook-allocstuff.c (-static) (test for excess errors) FAIL: libmudflap.c/hook2-allocstuff.c (-static) (test for excess errors) FAIL: libmudflap.c/pass-stratcliff.c (-static) (test for excess errors) FAIL: libmudflap.c/pass1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass16-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass16-frag.c (-static) (test for exce
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-09 22:38 --- FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test These above are caused by a bug in glibc. FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vectorized 1 loops 2 does not make a difference. FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) Unknown and you should look into g++.log. FAIL: abi_check ABI check is most likely an option pass to GCC or a difference between the base glibc which was used to generate the base and the version of glibc you use. FAIL: libmudflap.c/fail1-frag.c (-static) (test for excess errors) All libmudflap issues are glibc issues -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug fortran/29315] error passing an array derived from type element
--- Comment #5 from patchapp at dberlin dot org 2006-11-09 22:40 --- Subject: Bug number PR29315 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00582.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #13 from kkojima at gcc dot gnu dot org 2006-11-09 22:42 --- I've tested the patch in #9 with the trunk (rev. 118619) and got the same ICE in #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug fortran/29431] Not Implemented: complex character array constructors
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-09 22:49 --- Subject: Bug 29431 Author: pault Date: Thu Nov 9 22:49:12 2006 New Revision: 118631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118631 Log: 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29431 * trans-array.c(get_array_ctor_strlen): If we fall through to default, use a constant character length if it is available. 2006-11-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29431 * gfortran.dg/array_constructor_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #4 from sergstesh at yahoo dot com 2006-11-09 23:01 --- Thanks for your reply. Regarding " FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) Unknown and you should look into g++.log. " - you probably meant gcc/testsuite/g++/g++.log.sent file. If it's the case, here's what I've found: " FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) Excess errors: /usr/bin/ld: cannot find -lm ". I think that the missing library is /usr/lib/libm.so which is present on my system. Is it so that 'gcc' test process doesn't look for libraries in standard places ? And if youy remember by heart, where can I downlaod sources of 'libm' from ? Regarding 'glibc' - what is the best compatible with gcc-4.1.1 version ? And why the number of failure so drastically differs between gcc-4.1.1 and gcc-3.6.4 ? 'glibc' is the same in both cases. Regarding 'glibc' - what is the best compatible with gcc-4.1.1 ? Is there a 'glibc' version which is good for both gcc-3.4.6 and gcc-4.1.1 ? If not, what is the best compatible with gcc-3.4.6 ? Based on your answers I'll try to build 'glibc' myself - if necessary, it will be two different versions for gcc-3.4.6 and gcc-4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug fortran/29689] gfortran should use g77-compatible format for error message
--- Comment #8 from brooks at gcc dot gnu dot org 2006-11-09 23:17 --- Fixed on 4.2: svn 118628. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
[Bug c++/29787] std::vector can access negative value (std runtime bug?)
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-09 23:37 --- If you want bounds checking on std::vector, use the "at()" member function in place of operator[]. Otherwise, the overloaded operator[] is unchecked and just does a plain indexed-array reference. (If it is out-of-bounds, an exception will be thrown.) -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29787
[Bug tree-optimization/29788] [Optimization] ICE in var_ann, at tree-flow-inline.h:130
--- Comment #2 from aldot at gcc dot gnu dot org 2006-11-09 23:41 ---
Created an attachment (id=12583)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12583&action=view)
slightly smaller testcase
Confirmed.
Works on x86_64, ICEs on i686.
Also ICEs with gcc version 4.2.0 20061018 (experimental)
4.3.0 20061109 (experimental) gives
Breakpoint 1, var_ann (t=0xa7d911b8) at
../../../src/gcc-4.3/gcc/tree-flow-inline.h:130
130 gcc_assert (!t->common.ann || t->common.ann->common.type == VAR_ANN);
(gdb) p *t->common.ann
$9 = {common = {type = VAR_ANN, aux = 0x0, value_handle = 0x0}, vdecl = {common
= {
type = VAR_ANN, aux = 0x0, value_handle = 0x0}, out_of_ssa_tag = 0,
root_var_processed = 0, is_aliased = 1, used = 1, need_phi_state =
NEED_PHI_STATE_MAYBE,
in_vuse_list = 0, in_v_may_def_list = 0, is_heapvar = 0, symbol_mem_tag =
0x0,
may_aliases = 0x0, partition = 0, root_index = 0, current_def = 0xa7b583f0,
subvars = 0x0, escape_mask = 136}, fdecl = {common = {type = VAR_ANN, aux =
0x0,
value_handle = 0x0}, reference_vars_info = 0x2c}, stmt = {common = {type
= VAR_ANN,
aux = 0x0, value_handle = 0x0}, modified = 0, has_volatile_ops = 0,
makes_clobbering_call = 1, bb = 0x0, operands = {def_ops = 0x0, use_ops =
0x0,
maydef_ops = 0x0, vuse_ops = 0xa7b583f0, mustdef_ops = 0x0},
addresses_taken = 0x88,
uid = 1, histograms = 0x0}}
(gdb) c
Continuing.
./gfcbug4x-pr29788.f90: In function 'try_fit':
./gfcbug4x-pr29788.f90:31: internal compiler error: in var_ann, at
tree-flow-inline.h:130
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
[Bug tree-optimization/29788] [Optimization] ICE in var_ann, at tree-flow-inline.h:130
-- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-09 23:42:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
[Bug target/22110] Wrong ld search paths passed to libtool for 64-bit compiles
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-09 23:47 --- This was a bug in cctools. -- 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=22110
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #4 from echristo at apple dot com 2006-11-09 23:49 --- I'm going to mark this down as wontfix since I just added a port for ppc64-darwin and we don't need the file since the issue that caused host-darwin.c in the rs6000 backend to be created was fixed with tiger. -- echristo at apple dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug fortran/29791] New: ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
This is on x86_64-unknown-linux-gnu-gcc with GNU Fortran 95 (GCC) 4.3.0 20061109 r118621 2006-11-09 15:42:19 +0100 (since the anoynmous SVN does not work, I'm a bit hampered with testing. Using gfortran 4.2 it does not crash.) The error only occurs with -O2 but not with -O1: gfortran -O2 -c test.f90 test.f90: In function 'zsk_driver_cgnr': test.f90:8: internal compiler error: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776 subroutine zsk_driver_cgnr (opt, sol, sk_y) implicit none complex(8) :: sol(:) real(8) :: sk_y(:) interface subroutine opt() end subroutine opt end interface sk_y(1) = aimag(sol(1)) sol(1) = cmplx(0.0,1.0)*sk_y(1) end subroutine zsk_driver_cgnr -- Summary: ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal 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=29791
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #5 from echristo at apple dot com 2006-11-09 23:51 --- This appears to work with the change to add powerpc64-darwin support. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/27814] ICE building darwin-crt2.c in 64-bit darwin bootstrap
--- Comment #2 from echristo at apple dot com 2006-11-09 23:53 --- This appears fixed with the changes to add powerpc64-darwin support. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27814
[Bug driver/27845] Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc
--- Comment #2 from echristo at apple dot com 2006-11-09 23:54 --- I'd like you to retest this one with the new support I added for powerpc64-darwin. thanks. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27845
[Bug bootstrap/27814] ICE building darwin-crt2.c in 64-bit darwin bootstrap
--- Comment #3 from echristo at gcc dot gnu dot org 2006-11-09 23:57 --- Subject: Bug 27814 Author: echristo Date: Thu Nov 9 23:56:57 2006 New Revision: 118633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118633 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: trunk/gcc/config/rs6000/darwin64.h trunk/gcc/config/rs6000/host-ppc64-darwin.c trunk/gcc/config/rs6000/x-darwin64 Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/config/rs6000/darwin.h trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27814
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #5 from echristo at gcc dot gnu dot org 2006-11-09 23:57 --- Subject: Bug 28994 Author: echristo Date: Thu Nov 9 23:56:57 2006 New Revision: 118633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118633 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: trunk/gcc/config/rs6000/darwin64.h trunk/gcc/config/rs6000/host-ppc64-darwin.c trunk/gcc/config/rs6000/x-darwin64 Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/config/rs6000/darwin.h trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #6 from echristo at gcc dot gnu dot org 2006-11-09 23:57 --- Subject: Bug 26892 Author: echristo Date: Thu Nov 9 23:56:57 2006 New Revision: 118633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118633 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: trunk/gcc/config/rs6000/darwin64.h trunk/gcc/config/rs6000/host-ppc64-darwin.c trunk/gcc/config/rs6000/x-darwin64 Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/config/rs6000/darwin.h trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/27814] ICE building darwin-crt2.c in 64-bit darwin bootstrap
--- Comment #4 from echristo at gcc dot gnu dot org 2006-11-10 00:02 --- Subject: Bug 27814 Author: echristo Date: Fri Nov 10 00:02:21 2006 New Revision: 118634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118634 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure: Regenerate. * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: branches/gcc-4_2-branch/gcc/config/rs6000/darwin64.h branches/gcc-4_2-branch/gcc/config/rs6000/host-ppc64-darwin.c branches/gcc-4_2-branch/gcc/config/rs6000/x-darwin64 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config.gcc branches/gcc-4_2-branch/gcc/config.host branches/gcc-4_2-branch/gcc/config/rs6000/darwin.h branches/gcc-4_2-branch/gcc/configure branches/gcc-4_2-branch/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27814
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #7 from echristo at gcc dot gnu dot org 2006-11-10 00:02 --- Subject: Bug 26892 Author: echristo Date: Fri Nov 10 00:02:21 2006 New Revision: 118634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118634 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure: Regenerate. * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: branches/gcc-4_2-branch/gcc/config/rs6000/darwin64.h branches/gcc-4_2-branch/gcc/config/rs6000/host-ppc64-darwin.c branches/gcc-4_2-branch/gcc/config/rs6000/x-darwin64 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config.gcc branches/gcc-4_2-branch/gcc/config.host branches/gcc-4_2-branch/gcc/config/rs6000/darwin.h branches/gcc-4_2-branch/gcc/configure branches/gcc-4_2-branch/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #6 from echristo at gcc dot gnu dot org 2006-11-10 00:02 --- Subject: Bug 28994 Author: echristo Date: Fri Nov 10 00:02:21 2006 New Revision: 118634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118634 Log: 2006-11-09 Eric Christopher <[EMAIL PROTECTED]> PR bootstrap/26892 PR bootstrap/27814 PR other/28994 * configure: Regenerate. * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. * config.gcc (powerpc64-*-darwin*): New target. * config.host: Ditto. * config/rs6000/darwin64.h: New file. * config/rs6000/x-darwin64: Ditto. * config/rs6000/host-ppc64-darwin.c: Ditto. Added: branches/gcc-4_2-branch/gcc/config/rs6000/darwin64.h branches/gcc-4_2-branch/gcc/config/rs6000/host-ppc64-darwin.c branches/gcc-4_2-branch/gcc/config/rs6000/x-darwin64 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config.gcc branches/gcc-4_2-branch/gcc/config.host branches/gcc-4_2-branch/gcc/config/rs6000/darwin.h branches/gcc-4_2-branch/gcc/configure branches/gcc-4_2-branch/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #34 from dberlin at gcc dot gnu dot org 2006-11-10 00:03
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 21:48:25 -, dnovillo at redhat dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #33 from dnovillo at redhat dot com 2006-11-09 21:48 ---
> Subject: Re: [4.3 Regression] Misscompilation
> of spec2006 gcc
>
> dberlin at dberlin dot org wrote on 11/09/06 16:28:
>
> > Uh, LIM and store sinking are too. Roughly all of our memory
> > optimizations are.
> >
> They are? Really? Can you show me where exactly?
They won't get incorrect results. They will get less good results than
they do now.
Take LIM and store motion (sorry, i meant SM, not store sinking)
determine_max_movement relies on the VIRTUAL_KILL information to
determine what must be moved together. Because things that would
previously kill different symbol versions, now will kill the same
symbol version (due to being factored), it will add false dependencies
unless someone changes it.
Take the following example:
int e,f,g,h;
int main(int argc)
{
int *a, *b, *d;
int i;
a = &e;
if (argc)
a = &f;
b = &g;
if (argc)
b = &h;
d = &e;
if (argc)
d = &h;
for (i = 0; i < 50; i++)
{
*a = 1;
*b = 2;
*d = 3;
}
}
previously, you would have ...
# e_22 = V_MAY_DEF ;
# f_23 = V_MAY_DEF ;
*a_1 = 1;
# g_24 = V_MAY_DEF ;
# h_25 = V_MAY_DEF ;
*b_2 = 2;
# e_26 = V_MAY_DEF ;
# h_27 = V_MAY_DEF ;
*d_3 = 3;
Note that *a and *b do not vdef any symbol that is the same.
mem-ssa gives you (as of today):
# .MEM_16 = VDEF <.MEM_14, f_20>
*a_1 = 1;
# .MEM_17 = VDEF <.MEM_14, g_21>
*b_2 = 2;
# .MEM_18 = VDEF <.MEM_16, .MEM_17>
*d_3 = 3;
note that now *a and *b both vdef MEM_14.
SM is going to say these stores are dependent on each other because
they "kill" the same version of the same variable unless you teach it
to look at the get_loads_and_stores bitmap.
Previously, it would not.
> > The changes i have to make to PRE (and to the other things) to
> > account for this is actually to rebuild the non-mem-ssa-factored (IE
> > the current factored) form out of the chains by seeing what symbols
> > they really affect.
> >
> OK, so how come you were so positive about the new interface?
When have i been overabundantly positive?
I said I'd deal with it. I'm neither here nor there. I've relied on
your statements that you believe it will make things significantly
better without loss of precision. We are going to pay a cost in time
for passes to make use of this information. I believed you were aware
of this.
> I need to
> understand what was the great difficulty you ran into that made you
> change your mind. I need to see a specific example.
>
> See, the UD chains you get in mem-ssa are neither incomplete nor wrong.
Nobody said they are wrong, but I would actually argue they are no
longer really the same as SSA in a way that matters, if you want to
pick nits.
SSA variables have not only the property that they are *assigned to*
once, but the property that they are *defined* by a single operation.
Our current virtual operand scheme has this property.
Yours does not, because variables may be defined multiple times,
although they are still singley assigned.
You can argue this is not a requirement of SSA. Honestly, it makes no
difference to me. The upshot is that by losing this property, you
make them less useful than they could be.
> The symbols affected are right there in plain sight, so there is no
> loss of any information.
Errr, last time i looked, you had to call a function to get the
*actual* list of loads or stores affected by a statement.
Why does this matter?
All of our memory optimizations are trying to figure out three things:
1. Will two memory accesses return the same results (PRE, DSE)?
2. Do these two memory accesses have a dependency (PRE, SM, DSE, LIM).
3. If I hoist this memory to block X, will it still have the same
value as it does in block Y (PRE, SM, LIM).
Your stuff has no real affect on #2, but it makes #1 and #3 harder
(not less precise, mind you), at the cost of reducing the number of
operands.
It does so by factoring stores in a way that disables the ability to
see where loads are not *currently*, but *could*, validly be live. In
other words, it was previously possible to simply determine whether
two stores touched the same piece of memory by looking at the
versions. This is no longer true.
PRE does #1 and #3 through value numbering memory and tracking the
distinct live ranges of virtual variables.
SM and LIM do #3 by simply using dependency information to determine
what needs to be moved together and grouping operations that vdef the
same variable together.
SM and LIM will thus still get *correct* information in the above
example, but it's going to get false dependencies due to defs of the
same mem version, unless something disambiguates between those store
dependencies by looking at
[Bug tree-optimization/29791] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-10 00:04 --- #3 0x0054306e in internal_error (gmsgid=) at /home/tob/projects/gcc/gcc/diagnostic.c:588 #4 0x007694bc in tree_check_failed (node=0x2ab6d3f46870, file=0xa424a0 "/home/tob/projects/gcc/gcc/tree-ssa.c", line=776, function=0xa42e93 "verify_ssa") at /home/tob/projects/gcc/gcc/tree.c:6159 #5 0x00825e5b in verify_ssa (check_modified_stmt=1 '\001') at /home/tob/projects/gcc/gcc/tree-ssa.c:776 #6 0x00794fba in execute_todo (flags=16663) at /home/tob/projects/gcc/gcc/passes.c:804 #7 0x007951d7 in execute_one_pass (pass=0xcec7a0) at /home/tob/projects/gcc/gcc/passes.c:894 #8 0x007952fc in execute_pass_list (pass=0xcec7a0) at /home/tob/projects/gcc/gcc/passes.c:919 #9 0x0079530e in execute_pass_list (pass=0xce7a20) at /home/tob/projects/gcc/gcc/passes.c:920 #10 0x00497eae in tree_rest_of_compilation (fndecl=0x2ab6d3f367e0) at /home/tob/projects/gcc/gcc/tree-optimize.c:463 #11 0x007ef786 in cgraph_expand_function (node=0x2ab6d3f373c0) at /home/tob/projects/gcc/gcc/cgraphunit.c:1241 #12 0x007f236e in cgraph_optimize () at /home/tob/projects/gcc/gcc/cgraphunit.c:1306 #13 0x004609fd in gfc_be_parse_file (set_yydebug=) at /home/tob/projects/gcc/gcc/fortran/f95-lang.c:309 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #35 from dberlin at gcc dot gnu dot org 2006-11-10 00:12 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc > Take the above case. > If we simply use virtual variable versions to value number memory, we > will believe that *a and *b are possible stores to the same piece of > memory, even though they are not. In case it's not clear, this means while previously you would have determined you can move *b above *a simply by looking at the RHS, you can't anymore. My guess: Any memory optimization that wants to just eliminate redundant loads will be just fine with mem-ssa,. Any memory optimization that wants to eliminate redundant stores will have to be redesigned to not use chains to get maximum precision. Any memory optimization that wants to hoist either loads or stores will have to be redesigned to not use chains to determine where things can be moved to, in order to get maximum precision. At least, that's the way it appears to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29791] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-10 00:14 --- Slightly more reduced test case: subroutine zsk_driver_cgnr (opt, sol) implicit none interface subroutine opt() end subroutine opt end interface complex :: sol(:) sol(1) = cmplx(0.0,1.0)*aimag(sol(1)) end subroutine zsk_driver_cgnr or subroutine zsk_driver_cgnr (opt) implicit none interface subroutine opt() end subroutine opt end interface complex,allocatable :: sol(:) allocate(sol(5)) sol(1) = cmplx(0.0,1.0)*aimag(sol(1)) end subroutine zsk_driver_cgnr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug c++/2749] Internal compiler error while using template
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-11-10 00:18 --- Subject: Bug 2749 Author: jsm28 Date: Fri Nov 10 00:17:54 2006 New Revision: 118640 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118640 Log: gcc/ * config/soft-fp/op-4.c, config/soft-fp/op-common.h: Apply changes from ppc-ld-nofpu-20060920.txt from glibc bug 2749: 2006-09-20 Steven Munroe <[EMAIL PROTECTED]> Joe Kerian <[EMAIL PROTECTED]> * soft-fp/op-common.h (_FP_OVERFLOW_SEMIRAW): Always set inexact and overflow for infinity. (_FP_PACK_SEMIRAW): Update comment. Do not round if NaN. * soft-fp/op-4.h (__FP_FRAC_SUB_3, __FP_FRAC_SUB_4): Correct borrow handling for high words. Modified: branches/csl/sourcerygxx-4_1/ChangeLog.csl branches/csl/sourcerygxx-4_1/gcc/config/soft-fp/op-4.h branches/csl/sourcerygxx-4_1/gcc/config/soft-fp/op-common.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2749
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-10 00:19 --- Proposed patch: http://gcc.gnu.org/ml/fortran/2006-11/msg00285.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
