[Bug tree-optimization/27086] PRE looses SMT alias info
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-08 20:58 --- SMT.18091 is only ever mentioned in RVUSE_IN/OUT, not for any value handle, D.571521_46 also doesn't have a value handle. Created value VH.4677 for fieldEngineBase_5 Created value VH.4679 for *VH.4677 vuses: (SMT.18080_30) Created value VH.4710 for data_m Created value VH.4711 for VH.4679.VH.4710 vuses: (SMT.18080_30) Created value VH.4712 for blockControllerPtr_m Created value VH.4713 for VH.4711.VH.4712 vuses: (SMT.18080_30) Created value VH.4714 for ptr_m Created value VH.4715 for VH.4713.VH.4714 vuses: (SMT.18080_30) Created value VH.4716 for *VH.4715 vuses: (SMT.18083_148) Created value VH.4717 for pBegin_m Created value VH.4718 for VH.4716.VH.4717 vuses: (SMT.18083_148) Found partial redundancy for expression VH.4716.VH.4717 (VH.4718) NOTE: no flow-sensitive alias info for pretmp.18109_51 in pretmp.18111_48 = pretmp.18109_51->pBegin_m; NOTE: no flow-sensitive alias info for pretmp.18109_51 in pretmp.18111_48 = pretmp.18109_51->pBegin_m; Inserted pretmp.18111_48 = pretmp.18109_51->pBegin_m in predecessor 23 why's that SMT.18083 (if not 18091) not added to the stmt? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|PRE loses SMT alias info|PRE looses SMT alias info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27086
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13 --- Subject: Re: IVs with the same evolution not eliminated > The new SCC value numberer for PRE i'm working on gets this case right (and > this is in fact, one of the advantages of SCC based value numbering). Is the SCC-VN patch I posted long ago still of some use to you, or are you writing something new from scratch? (See http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00211.html) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug tree-optimization/27086] PRE loses SMT alias info
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 21:46 --- This really has nothing to do with PRE except for PRE adding a new variable which contains no aliasing info attached to it so we lose information because our aliasing system sucks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27086
[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-04-08 21:47 --- Checking wether size is negative won't work as a complete fix for this. Consider the following example: $ cat a4.f90 program main real, allocatable:: a(:,:) allocate (a(1:-1,1:-1)) print *,size(a) end program main This (correctly) prints 0, but the allocated size is still nonzero (which we probably don't want). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26017
[Bug tree-optimization/27086] PRE loses SMT alias info
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-08 21:54 --- add... may_alias... after... PRE! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27086
[Bug tree-optimization/27087] New: [4.1,4.2 regression] ICE in merge_alias_info
[ forwarded from http://bugs.debian.org/361501 ]
% cat ice2.c
extern int ptbl[16];
extern int ctbl[16];
void doViews(void) {
int *p = ptbl, *c = ctbl;
while (1) {
c++;
p++;
if (*p && (p != c || *c))
return;
}
}
% gcc-4.0 -c -O2 ice2.c
% gcc -c -O2 ice2.c
ice2.c: In function 'doViews':
ice2.c:4: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.1,4.2 regression] ICE in merge_alias_info
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug tree-optimization/27088] New: [4.2 regression] Segfault with inlining producing negative shift count
[EMAIL PROTECTED]:/tmp% cat min4.c
inline unsigned length() {
return 0;
}
unsigned add_new_phrase() {
return 16 / (1 << (length() - 1));
}
[EMAIL PROTECTED]:/tmp% gcc -c min4.c
[EMAIL PROTECTED]:/tmp% gcc -c -O min4.c
min4.c: In function 'add_new_phrase':
min4.c:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
No problem with 4.1.0 or earlier.
Falk
--
Summary: [4.2 regression] Segfault with inlining producing
negative shift count
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27088
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-08 23:11 --- Here is the patch which fixes this issue for me: Index: cp-objcp-common.c === --- cp-objcp-common.c (revision 112789) +++ cp-objcp-common.c (working copy) @@ -179,7 +179,7 @@ cxx_types_compatible_p (tree x, tree y) if (POINTER_TYPE_P (x) && POINTER_TYPE_P (y) && TYPE_MODE (x) == TYPE_MODE (y) && TYPE_REF_CAN_ALIAS_ALL (x) == TYPE_REF_CAN_ALIAS_ALL (y) - && same_type_p (TREE_TYPE (x), TREE_TYPE (y))) + && same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (x), TREE_TYPE (y))) return 1; return 0; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug middle-end/27088] [4.2 regression] Segfault with inlining producing negative shift count
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:13 --- Confirmed, the ICE is in fold-const. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-08 23:13:15 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27088
[Bug middle-end/27088] [4.2 regression] Segfault with inlining producing negative shift count
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 23:14 --- in fact when folding 16 / 0 But the 0 has overflowed bit marked so ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27088
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16 --- Confirmed, the ICE is during DOM. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-04-08 23:16:45 date|| Summary|[4.1,4.2 regression] ICE in |[4.1/4.2 regression] ICE in |merge_alias_info|merge_alias_info Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
Re: [Bug tree-optimization/19590] IVs with the same evolution not eliminated
> --- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
> ---
> Subject: Re: IVs with the same evolution not eliminated
>
> > The new SCC value numberer for PRE i'm working on gets this case right (and
> > this is in fact, one of the advantages of SCC based value numbering).
>
> Is the SCC-VN patch I posted long ago still of some use to you, or are
> you writing something new from scratch?
I ended up rewriting it from scratch, for other reasons.
In particular
1. I keep separate hash tables for unary, binary, references, and phi
expressions, each with their own structure
This is because you really want valuized structures in the hash table.
Your implementation will get the wrong answers during optimistic lookup
at times, because the value representative for a phi argument can change
and will get hashed to the wrong value.
2. I keep track of what expressions simplified to, and whether they have
constants in the simplified expression. This enables much more
simplification that simply storing the value number name.
In particular, in something like
int main(int argc)
{
int a;
int b;
int c;
int d;
a = argc + 4;
b = argc + 8;
c = a & b;
d = a + 4;
return c + d;
}
We will prove that d and b have the same value.
BTW, you missed the part of the thesis where he explains that phi nodes
in different blocks can't be congruent to each other (this isn't quite
true, but it's a much harder property to prove).
3. I needed the structures i made so i could directly transform the
results into value handles.
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-04-08 23:20
---
Subject: Re: IVs with the same evolution not
eliminated
> --- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
> ---
> Subject: Re: IVs with the same evolution not eliminated
>
> > The new SCC value numberer for PRE i'm working on gets this case right (and
> > this is in fact, one of the advantages of SCC based value numbering).
>
> Is the SCC-VN patch I posted long ago still of some use to you, or are
> you writing something new from scratch?
I ended up rewriting it from scratch, for other reasons.
In particular
1. I keep separate hash tables for unary, binary, references, and phi
expressions, each with their own structure
This is because you really want valuized structures in the hash table.
Your implementation will get the wrong answers during optimistic lookup
at times, because the value representative for a phi argument can change
and will get hashed to the wrong value.
2. I keep track of what expressions simplified to, and whether they have
constants in the simplified expression. This enables much more
simplification that simply storing the value number name.
In particular, in something like
int main(int argc)
{
int a;
int b;
int c;
int d;
a = argc + 4;
b = argc + 8;
c = a & b;
d = a + 4;
return c + d;
}
We will prove that d and b have the same value.
BTW, you missed the part of the thesis where he explains that phi nodes
in different blocks can't be congruent to each other (this isn't quite
true, but it's a much harder property to prove).
3. I needed the structures i made so i could directly transform the
results into value handles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-08 23:28 --- I am testing the C++ patch right now. It is always a better idea to fix a pass to do what it should be doing instead of hacking another one to do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-09 00:58 ---
Here is a testcase making sure that fold does not get in the way:
extern int ptbl[4];
extern int ctbl[4];
void doViews(void) {
int *c = ctbl, *p = ptbl;
while (1)
{
p++;
c++;
if (*p)
{
if (c == p)
{
if (*c)
return;
}
else
return;
}
}
g();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug fortran/27089] New: Module procedure with explicit result does not pass type to specification expression.
This fault occurs in the compilation of tonto-2.2. A fix will be posted to the list in a few minutes. There is still another problem with tonto that I am still investigating. I will post that just as soon as I isolate it. Paul module test publicn_elements_uncommon_with_ interface n_elements_uncommon_with_ module procedure n_elements_uncommon_with end interface contains pure function n_elements_uncommon_with(x) result(res) integer(4), dimension(:), intent(in) :: x integer(4) :: res res = size (x, 1) end function pure function elements_uncommon_with(x) result(res) integer(4), dimension(:), intent(in) :: x integer(4), dimension(n_elements_uncommon_with_(x)) :: res res = x end function end module test use test integer(4) :: z(4) z = 1 print *, elements_uncommon_with (z) print *, n_elements_uncommon_with_ (z) end -- Summary: Module procedure with explicit result does not pass type to specification expression. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27089
[Bug fortran/27089] Module procedure with explicit result does not pass type to specification expression.
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-09 04:55 --- Duuuh! I forgot a little something... In file test.f90:19 integer(4), dimension(n_elements_uncommon_with_(x)) :: res 1 Error: Expression at (1) must be of INTEGER type In file test.f90:19 Repeated four times. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27089
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-09 05:30:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug c++/26986] [4.2 Regression] Segfault with iostream code
--- Comment #2 from falk at debian dot org 2006-04-08 08:06 --- I cannot reproduce this anymore with 4.2.0 20060407, so closing. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26986
[Bug target/8883] Alpha: regalloc too eager to use FP regs on EV6
--- Comment #4 from falk at debian dot org 2006-04-08 08:25 --- I don't see this problem anymore in 4.2.0 20060407, so closing. -- falk at debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8883
[Bug c++/27082] New: segfault with virtual class and visibility ("hidden")
% cat bug.c
struct Virtual {
virtual ~Virtual() { }
} __attribute__ ((visibility ("hidden")));
const void* get_vptr() {
return new Virtual();
}
const void* p = get_vptr();
% g++ -c bug.c
bug.c: In constructor 'Virtual::Virtual()':
bug.c:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This looks similar to PR 26986, which I cannot reproduce anymore. Maybe it's
some kind of memory corruption within the visibility handling?
--
Summary: segfault with virtual class and visibility ("hidden")
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug c++/27082] segfault with virtual class and visibility ("hidden")
--- Comment #1 from falk at debian dot org 2006-04-08 10:20 --- Here is a backtrace. [EMAIL PROTECTED]:/src/gcc-2006.04.07/build/gcc% gdb cc1plus GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-linux-gnu"...r Using host libthread_db library "/lib/libthread_db.so.1". Breakpoint 1 at 0x1202dade0: file ../../gcc/diagnostic.c, line 642. Breakpoint 2 at 0x1202dad28: file ../../gcc/diagnostic.c, line 587. Function "exit" not defined. Function "abort" not defined. (gdb) r /tmp/bug.cc Starting program: /src/gcc-2006.04.07/build/gcc/cc1plus /tmp/bug.cc virtual Virtual::~Virtual() Virtual::~Virtual() virtual Virtual::~Virtual() virtual Virtual::~Virtual() const void* get_vptr() Virtual::Virtual() Virtual::Virtual() Virtual::Virtual() void __static_initialization_and_destruction_0(int, int) void _GLOBAL__I__Z8get_vptrv() Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: Virtual::Virtual()During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. Program received signal SIGSEGV, Segmentation fault. validize_mem (ref=0x0) at ../../gcc/explow.c:529 529 if (!MEM_P (ref)) (gdb) bt #0 validize_mem (ref=0x0) at ../../gcc/explow.c:529 During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. #1 0x0001204f3bd0 in alpha_expand_mov (mode=DImode, operands=0x11f764dd0) at ../../gcc/config/alpha/alpha.c:2239 #2 0x0001203c64a8 in gen_movdi (operand0=0x23335a0, operand1=0x2333580) at alpha.md:5646 During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. #3 0x00012033a478 in emit_move_insn_1 (x=0x23335a0, y=0x2333580) at ../../gcc/expr.c:3089 #4 0x00012033aa30 in emit_move_insn (x=0x23335a0, y=0x0) at ../../gcc/expr.c:3278 #5 0x000120312e88 in force_reg (mode=DImode, x=0x2333580) at ../../gcc/explow.c:660 #6 0x0001204f3064 in alpha_legitimize_address (x=0x11f764f60, scratch=0x2333540, mode=DImode) at ../../gcc/config/alpha/alpha.c:1030 #7 0x0001204f3c0c in alpha_expand_mov (mode=DImode, operands=0x11f764f60) at ../../gcc/config/alpha/alpha.c:2207 #8 0x0001203c64a8 in gen_movdi (operand0=0x2333540, operand1=0x21dffa0) at alpha.md:5646 #9 0x00012033a478 in emit_move_insn_1 (x=0x2333540, y=0x21dffa0) at ../../gcc/expr.c:3089 #10 0x00012033aa30 in emit_move_insn (x=0x2333540, y=0x0) at ../../gcc/expr.c:3278 #11 0x0001203411d0 in store_expr (exp=0x233f840, target=, call_param_p=0) at ../../gcc/expr.c:4481 #12 0x00012032b8dc in expand_assignment (to=0x2344420, from=0x233f840) at ../../gcc/expr.c:4203 #13 0x000120331620 in expand_expr_real_1 (exp=, target=, tmode=VOIDmode, modifier=, alt_rtl=0x0) at ../../gcc/expr.c:8519 #14 0x00012033a004 in expand_expr_real (exp=0x21e2bd0, target=0x21de400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/expr.c:6625 During symbol reading, unsupported tag: 'DW_TAG_const_type'. During symbol reading, unsupported tag: 'DW_TAG_const_type'. #15 0x000120466180 in expand_expr_stmt (exp=0x0) at expr.h:494 #16 0x0001204b27dc in expand_gimple_basic_block (bb=0x234a280) at ../../gcc/cfgexpand.c:1368 #17 0x0001204b3dcc in tree_expand_cfg () at ../../gcc/cfgexpand.c:1627 #18 0x0001204ae460 in execute_one_pass (pass=0x120731328) at ../../gcc/passes.c:863 #19 0x0001204ae678 in execute_pass_list (pass=0x120731328) at ../../gcc/passes.c:910 #20 0x0001201ac16c in tree_rest_of_compilation (fndecl=0x2338e00) at ../../gcc/tree-optimize.c:418 #21 0x000120100b98 in expand_body (fn=0x2338e00) at ../../gcc/cp/semantics.c:3012 #22 0x0001204fb050 in cgraph_expand_f
[Bug c++/27083] New: [4.1,4.2 regression] bit-field value not narrowed
[EMAIL PROTECTED]:/tmp% cat test.c
#ifdef __cplusplus
extern "C"
#endif
void abort(void);
__attribute__((noinline))
unsigned long f(const unsigned long x) {
struct { unsigned long x : 1; } s;
s.x = x;
return s.x;
}
int main() {
if (f(3) != 1)
abort();
}
[EMAIL PROTECTED]:/tmp% gcc test.c && ./a.out
[EMAIL PROTECTED]:/tmp% g++ test.c && ./a.out
[EMAIL PROTECTED]:/tmp% g++ -O test.c && ./a.out
zsh: abort (core dumped) ./a.out
not a problem with 4.0 or earlier
--
Summary: [4.1,4.2 regression] bit-field value not narrowed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27083
[Bug tree-optimization/27084] New: Does not propagate memory load base through useless type conversion
Consider
struct Data {
int get() const { return value; }
int value;
};
struct Object {
int operator[](int i) const { return data_m->get(); }
Data *data_m;
};
int foo(Object&o)
{
return o[0];
}
here we have after forwprop
int foo(Object&) (o)
{
struct Object * const this;
struct Data * D.20003;
int D.20005;
struct Data * const this;
:
this_2 = o_1;
D.20003_4 = this_2->data_m;
this_5 = D.20003_4;
D.20005_6 = this_5->value;
D.20005_7 = D.20005_6;
D.20005_8 = D.20005_7;
D.20005_9 = D.20005_8;
D.20005_10 = D.20005_9;
return D.20005_10;
}
both memory loads could load from o_1 and D.20003_4 respectively.
--
Summary: Does not propagate memory load base through useless type
conversion
Product: gcc
Version: 4.2.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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug fortran/25031] [4.1 only] Allocatable array can be reallocated.
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-04-08 17:05 --- Subject: Bug 25031 Author: tkoenig Date: Sat Apr 8 17:05:52 2006 New Revision: 112783 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112783 Log: 2006-04-08 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 Backport from mainline * trans-array.h: Adjust gfc_array_allocate prototype. * trans-array.c (gfc_array_allocate): Change type of gfc_array_allocatate to bool. Function returns true if it operates on an array. Change second argument to gfc_expr. Find last reference in chain. If the function operates on an allocatable array, emit call to allocate_array() or allocate64_array(). * trans-stmt.c (gfc_trans_allocate): Code to follow to last reference has been moved to gfc_array_allocate. * trans.h: Add declaration for gfor_fndecl_allocate_array and gfor_fndecl_allocate64_array. (gfc_build_builtin_function_decls): Add gfor_fndecl_allocate_array and gfor_fndecl_allocate64_array. 2006-04-08 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 Backport from mainline * runtime/memory.c: Adjust copyright years. (allocate_array): New function. (allocate64_array): New function. * libgfortran.h (error_codes): Add ERROR_ALLOCATION. 2006-04-08 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 * gfortran.dg/multiple_allocation_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/multiple_allocation_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-array.h branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25031
[Bug fortran/25031] [4.1 only] Allocatable array can be reallocated.
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-04-08 17:06 --- Fixed on 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25031
[Bug tree-optimization/27084] Does not propagate memory load base through useless type conversion
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-08 17:09 --- Created an attachment (id=11227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11227&action=view) prototype patch I have a prototype patch for forwprop that handles this, but somehow messes up virtual operands. We get a non-ssaname VUSE: # VUSE ; D.6255_561 = D.6253_558->typeD.4890 during build of libcpp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug tree-optimization/27084] Does not propagate memory load base through useless type conversion
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-08 17:21 --- Hm, we have from DCE to forwprop struct cpp_token * D.6254; struct cpp_token * D.6253; # temp_1334 = V_MAY_DEF ; # unsignedp_1335 = V_MAY_DEF ; # op_1336 = V_MAY_DEF ; # SMT.698_1337 = V_MAY_DEF ; # SMT.700_1338 = V_MAY_DEF ; # SMT.703_1339 = V_MAY_DEF ; D.6253_558 = cpp_get_token (pfile_475); D.6254_560 = D.6253_558; - # VUSE ; - D.6255_561 = D.6254_560->type; + D.6255_561 = D.6253_558->type; D.6256_562 = (cpp_ttype) D.6255_561; # SFT.637_563 = V_MUST_DEF ; op.op = D.6256_562; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug tree-optimization/27084] Does not propagate memory load base through useless type conversion
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-08 18:31 --- Of course this is from tramp3d, and I hope fixing it would enable the hoisting of more invariant loads out of the inner loops. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||22501 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug tree-optimization/27085] New: [4.2 regression] ICE in add_virtual_operand
[ forwarded from http://bugs.debian.org/361441 ]
% cat ice.c
typedef struct {
int array_inputs;
} TNLcontext;
void f(void *);
void _tnl_upgrade_client_data (void *swtnl_context) {
f(&((TNLcontext *) swtnl_context)->array_inputs);
int is_writeable = 0;
int *inputs = &((TNLcontext *) swtnl_context)->array_inputs;
f(&is_writeable);
*inputs = 0;
}
% gcc -c -O2 ice.c
ice.c: In function '_tnl_upgrade_client_data':
ice.c:7: internal compiler error: in add_virtual_operand, at
tree-ssa-operands.c:1354
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
No problem with 4.1.
Falk
--
Summary: [4.2 regression] ICE in add_virtual_operand
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27085
[Bug c++/27083] [4.1,4.2 regression] bit-field value not narrowed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 18:56 --- This is a dup of bug 26534. *** This bug has been marked as a duplicate of 26534 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27083
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-08 18:56 --- *** Bug 27083 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug tree-optimization/27084] Does not propagate memory load base through useless type conversion
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-08 18:58 --- hmhm, merge_alias_info seems to fix it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug target/27082] segfault with virtual class and visibility ("hidden")
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 19:04 --- Looking at the backtrace, this looks like a target specific issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug tree-optimization/27085] [4.2 regression] ICE in add_virtual_operand
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27085
[Bug tree-optimization/27084] Does not propagate memory load base through useless type conversion
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-08 19:09 --- forwrop when propragating better be using merge_ssa_info anyways, just like copy prop and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug tree-optimization/27086] New: PRE looses SMT alias info
Basically, we have before PRE: : # c_92 = PHI ; :; # VUSE ; D.571515_36 = fieldEngineBase_5->stride_m; D.571516_37 = m_104 * D.571515_36; D.571517_38 = c_92 + D.571516_37; # VUSE ; D.571521_46 = fieldEngineBase_5->data_m.blockControllerPtr_m.ptr_m; # VUSE ; D.571523_49 = D.571521_46->pBegin_m; # VUSE ; D.571527_54 = fieldEngineBase_5->data_m.offset_m; after PRE: NOTE: no flow-sensitive alias info for pretmp.18109_51 in pretmp.18111_48 = pretmp.18109_51->pBegin_m; : :; # VUSE ; pretmp.18106_60 = fieldEngineBase_5->stride_m; pretmp.18108_52 = pretmp.18106_60 * m_104; # VUSE ; pretmp.18109_51 = fieldEngineBase_5->data_m.blockControllerPtr_m.ptr_m; pretmp.18111_48 = pretmp.18109_51->pBegin_m; # VUSE ; pretmp.18113_35 = fieldEngineBase_5->data_m.offset_m; note the missing # VUSE ; on the dereference of pretmp.18109_51. verify_ssa only detects this later after loopinit which adds back the VUSE, but with a bare unrenamed SMT.18091. Oh, this may be the n-th dup of the same problem - just I didn't see PRE mentioned sofar. And no, I don't have a (small) testcase yet - this is in compiling tramp3d-v5 with custom patches. -- Summary: PRE looses SMT alias info Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27086
