[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-22 06:36 --- Minimal example: implicit none real, TARGET :: a(0:100) real, pointer :: p(:) p = a print *, lbound(a), ubound(a) print *, lbound(p), ubound(p) end Prints: 0 100 1 101 instead of (ifort, NAG f95, g95): 0 100 0 100 7.4.2.1 Data pointer assignment If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of the corresponding dimension of data-target. [...] the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.60) applied to the corresponding dimension of data-target. The upper bound of each dimension is one less than the sum of the lower bound and the extent. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-08-22 06:36:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-08-22 08:01 --- Subject: Bug 32563 Author: rguenth Date: Wed Aug 22 08:00:55 2007 New Revision: 127688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127688 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/32563 * tree.c (host_integerp): Treat sizetype as signed as it is sign-extended. * g++.dg/torture/pr32563.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr32563.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-22 08:07 --- Subject: Bug 32563 Author: rguenth Date: Wed Aug 22 08:07:11 2007 New Revision: 127689 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127689 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/32563 * tree.c (host_integerp): Treat sizetype as signed as it is sign-extended. * g++.dg/torture/pr32563.C: New testcase. Backport from mainline: 2007-05-30 Richard Guenther [EMAIL PROTECTED] * g++.dg/dg.exp: Prune torture/. * g++.dg/torture/dg-torture.exp: New testsuite. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/torture/ - copied from r125200, trunk/gcc/testsuite/g++.dg/torture/ branches/gcc-4_2-branch/gcc/testsuite/g++.dg/torture/pr32563.C - copied unchanged from r127688, trunk/gcc/testsuite/g++.dg/torture/pr32563.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/dg.exp branches/gcc-4_2-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-22 08:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug tree-optimization/32733] [4.3 regression] error: definition in block 11 does not dominate use in block 12
--- Comment #6 from cato at df dot lth dot se 2007-08-22 08:28 --- Subject: Re: [4.3 regression] error: definition in block 11 does not dominate use in block 12 This seems to work now. I have successfully bootstrapped revision 127624 on i386-unknown-netbsdelf3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug tree-optimization/33145] New: Should combine float/int conversion and rounding functions
long
foo (int i)
{
float x;
x = i;
return __builtin_lroundf (x);
}
and
long
foo (int i)
{
return __builtin_lroundf ((float)i);
}
should generate the same code. The former is before expansion
return __builtin_lroundf ((float) i);
which is unfolded while the latter is
return (long int) (float) i;
This has to be addressed in a tree-combiner.
--
Summary: Should combine float/int conversion and rounding
functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
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=33145
[Bug tree-optimization/33146] New: [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
I get the following ICE with current trunk. This was introduced between 20070616 (works) and 20070720 (ICE). (sid)25899:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O -Wall jasper-jpc_t1enc.c jasper-jpc_t1enc.c: In function 'foo': jasper-jpc_t1enc.c:10: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:136 Please submit a full bug report, -- Summary: [4.3 Regression] ICE in build_polynomial_chrec, at tree- chrec.h:136 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
--- Comment #1 from tbm at cyrius dot com 2007-08-22 08:34 --- Maybe caused by: 2007-06-19 Sebastian Pop [EMAIL PROTECTED] PR tree-optimization/32367 * tree-chrec.h (build_polynomial_chrec): Verify that the left hand side -- tbm at cyrius dot com changed: What|Removed |Added CC||sebpop at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
--- Comment #2 from tbm at cyrius dot com 2007-08-22 08:34 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
typedef struct
{
int end;
int term;
}
jpc_enc_pass_t;
void foo(int numpasses, jpc_enc_pass_t *p)
{
jpc_enc_pass_t *pass;
jpc_enc_pass_t *termpass;
for (pass = p; pass != termpass; ++pass)
if (!pass-term)
{
termpass = pass;
while (termpass - pass numpasses !termpass-term)
++termpass;
pass-end = termpass-end;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-22 08:44 --- Subject: Bug 33142 Author: rguenth Date: Wed Aug 22 08:43:53 2007 New Revision: 127691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127691 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33142 * tree-vrp.c (extract_range_from_unary_expr): Compare with TYPE_MIN/MAX_VALUE using tree_int_cst_equal. * gcc.c-torture/execute/pr33142.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr33142.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-22 08:46 --- Subject: Bug 33142 Author: rguenth Date: Wed Aug 22 08:45:58 2007 New Revision: 127692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127692 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33142 * gcc.c-torture/execute/pr33142.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr33142.c - copied unchanged from r127691, branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr33142.c Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-22 08:47 --- Subject: Bug 33142 Author: rguenth Date: Wed Aug 22 08:47:26 2007 New Revision: 127693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127693 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33142 * gcc.c-torture/execute/pr33142.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr33142.c - copied unchanged from r127691, branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr33142.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 08:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.3 |4.1.2 Resolution||FIXED Target Milestone|4.1.4 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-22 09:05 --- We indeed have a strange chrec here: (gdb) call debug_tree (left) negate_expr 0x2afca7c12240 type pointer_type 0x2afca7be9b60 type record_type 0x2afca7be9a90 jpc_enc_pass_t type_0 DI size integer_cst 0x2afca71ddb70 constant invariant 64 unit size integer_cst 0x2afca71ddba0 constant invariant 8 align 32 symtab 0 alias set -1 canonical type 0x2afca7be9820 fields field_decl 0x2afca72a90b0 end context translation_unit_decl 0x2afca7be9ea0 D.2029 pointer_to_this pointer_type 0x2afca7be9b60 sizes-gimplified public unsigned DI size integer_cst 0x2afca71ddb70 64 unit size integer_cst 0x2afca71ddba0 8 align 64 symtab 0 alias set -1 canonical type 0x2afca7be9c30 arg 0 ssa_name 0x2afca7c02060 type pointer_type 0x2afca7be9b60 volatile visited var parm_decl 0x2afca71e45a0 p def_stmt nop_expr 0x2afca7bff6c0 version 5 ptr-info 0x2afca7bfe560 (gdb) call debug_tree (right) integer_cst 0x2afca7c0ae40 type pointer_type 0x2afca7be9b60 constant invariant public overflow 18446744073709551608 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-22 09:05:54 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug middle-end/33137] [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
[Bug libfortran/23138] [mingw32] real(16) values are printed incorrectly
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-08-22 10:00 --- Good news: mingw now includes a standard-conforming implementation of the printf functions. To quote Brian Dessent: there is a replacement snprintf named __mingw_snprintf (and similarly for vsnprintf) to work around all of the MSVCRT cruft. This replacement supports the standard long double format specifiers. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-21 14:02:03 |2007-08-22 10:00:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 10:02 --- The patch doesn't address the problem it seems. Instead I'll let the middle-end decide which arrays are compatible instead of differing to the frontend in useless_type_conversion_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug target/33115] -march=native is not supported under x86 darwin
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-22 10:03 --- *** Bug 33144 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fago at caltech dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33115
[Bug driver/33144] -march=native does not work on darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 10:03 --- I just fixed this for 4.3.0 (this is not a regression so it will not be fixed in 4.2.0). *** This bug has been marked as a duplicate of 33115 *** -- 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=33144
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-22 10:07 ---
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
A5 array5;
A10 *ap;
void
f (void)
{
int ap;
{
extern IA *ap;
ap = array5;
}
}
The real problem is that the frontend creates a conversion to (int[] *) rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug tree-optimization/32949] suboptimal address generation for int indices on 64-bit targets
--- Comment #2 from amonakov at gmail dot com 2007-08-22 10:13 --- *** scev_probably_wraps_p (tree base, tree s *** 2969,2977 2032, 2040, 0, 8, ..., but the code is still legal. */ if (chrec_contains_undetermined (base) ! || chrec_contains_undetermined (step) ! || TREE_CODE (step) != INTEGER_CST) ! return true; if (integer_zerop (step)) return false; --- 2969,2975 2032, 2040, 0, 8, ..., but the code is still legal. */ if (chrec_contains_undetermined (base) ! || chrec_contains_undetermined (step)) if (integer_zerop (step)) return false; Zdenek, isn't 'return true' missing here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32949
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-22 10:29 --- So we have a NEGATIVE_EXPR of a pointer type that is just wrong. I am going to look into this further (plus I guess I need to add more checking). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-22 10:53 --- *** Bug 33137 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug middle-end/33137] [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-22 10:53 --- *** This bug has been marked as a duplicate of 32573 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-22 11:23 --- real, TARGET :: a(0:100) real, pointer :: p(:) p = a print *, lbound(a), ubound(a) print *, lbound(p), ubound(p) end This generates the following code: struct array1_real4 p; real4 a[101]; p.data = 0B; p.dtype = 281; p.dim[0].lbound = 1; p.dim[0].ubound = 101; p.dim[0].stride = 1; p.data = (void *) a[0]; p.offset = -1; -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.3 4.2.1 4.3.0 Last reconfirmed|2007-08-22 06:36:24 |2007-08-22 11:23:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-22 11:43 --- Subject: Bug 33007 Author: rguenth Date: Wed Aug 22 11:43:32 2007 New Revision: 127701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127701 Log: 2007-08-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/33007 * builtins.c (expand_builtin_int_roundingfn): Replace call argument wrapped with SAVE_EXPR directly. (expand_builtin_int_roundingfn_2): Likewise. * gcc.dg/pr33007.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr33007.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug middle-end/33007] [4.2 Regression] builtin lround doesn't work
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-22 11:44 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.1 Known to work||4.1.2 Summary|[4.3 Regression] builtin|[4.2 Regression] builtin |lround doesn't work |lround doesn't work Target Milestone|4.3.0 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-08-22 11:45 --- Nevermind - only fails on suse-4_2 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.1 | Known to work|4.1.2 |4.1.2 4.2.1 Resolution||FIXED Summary|[4.2 Regression] builtin|[4.3 Regression] builtin |lround doesn't work |lround doesn't work Target Milestone|4.2.2 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug libfortran/23272] [mingw32] inquire via filename fails
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-28 14:09:37 |2007-08-22 11:53:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23272
[Bug c/33147] New: ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -mhard-float -O
This file:
void t(double foo)
{
puts(foo = 1.0 ? foo : bar);
}
provokes ICE segfault when compiled with
gcc -O -mfpu=maverick -mcpu=ep9312 -mhard-float -c t.c
Confirmed same behaviour in:
- native Debian armel gcc-4.1.3 arm-linux-gnueabi
- native Debian arm gcc-4.1.2 on arm-linux-gnu
- cross-compiler gcc-4.1.1 on i386-linux-gnu target arm-linux-gnueabi
The SEGV goes away if -msoft-float is used instead of -mhard-float;
removing -O also makes the compilation succeed.
Strangely, explicitly supplying the -f flags that -O is said to enable:
-fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time -fmerge-constants
-fomit-frame-pointer
does not provoke the segfault, but adding -O to the the list does.
Here are the native gcc-4.1.3 details:
Target: arm-linux-gnueabi
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,obj-c++,treelang --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --disable-libssp --enable-checking=release arm-linux-gnueabi
Thread model: posix
gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)
Output:
t.c: In function 't':
t.c:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -
mhard-float -O
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martinwguy at yahoo dot it
GCC build triplet: arm-linux-gnueabi
GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33147
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #9 from rask at gcc dot gnu dot org 2007-08-22 12:56 --- Subject: Bug 32557 Author: rask Date: Wed Aug 22 12:56:35 2007 New Revision: 127703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127703 Log: PR rtl-optimization/32557 * df-problems.c (df_note_bb_compute): Use mws-start_regno instead of REGNO (mws-mw_reg). Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug rtl-optimization/33148] New: [4.2 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
typedef struct _IO_FILE FILE;
typedef unsigned long potrace_word;
struct potrace_bitmap_s {
int dy;
potrace_word *map;
};
typedef struct potrace_bitmap_s potrace_bitmap_t;
struct bmp_info_s {
unsigned int w;
unsigned int h;
unsigned int bits;
unsigned int comp;
};
typedef struct bmp_info_s bmp_info_t;
static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp)
{
bmp_info_t bmpinfo;
unsigned int b;
unsigned int i;
potrace_bitmap_t *bm;
int mask;
unsigned int y;
int col1[2];
if (col1[0] col1[1])
mask = 0xff;
else
mask = 0;
for (y=0; ybmpinfo.h; y++)
for (i=0; ibmpinfo.w; i++)
{
b ^= mask;
*(bm-map + y*bm-dy) |= (potrace_word)b i;
}
return -1;
}
int bm_read(FILE *f, double threshold, potrace_bitmap_t **bmp, int *magic)
{
if (magic[0] == 'B' magic[1] == 'M')
return bm_readbody_bmp(f, threshold, bmp);
return 0;
}
ICEs with
./cc1 -quiet bitmap_io.min.i -O
bitmap_io.min.i: In function 'bm_read':
bitmap_io.min.i:41: internal compiler error: in trunc_int_for_mode, at
explow.c:56
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
56gcc_assert (SCALAR_INT_MODE_P (mode));
#1 0x005c0bd3 in trunc_int_for_mode (c=255, mode=CCmode)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/explow.c:56
#2 0x005ae2b0 in gen_int_mode (c=255, mode=CCmode)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/emit-rtl.c:404
#3 0x0079e4e7 in simplify_binary_operation_1 (code=AND, mode=DImode,
op0=0x2b2c79301190, op1=0x2b2c78e6cae0, trueop0=0x2b2c79301190,
trueop1=0x2b2c78e6cae0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/simplify-rtx.c:2224
#4 0x0079b76d in simplify_binary_operation (code=AND, mode=DImode,
op0=0x2b2c79301190, op1=0x2b2c78e6cae0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/simplify-rtx.c:1473
#5 0x00797e7f in simplify_gen_binary (code=AND, mode=DImode,
op0=0x2b2c79301190, op1=0x2b2c78e6cae0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/simplify-rtx.c:119
#6 0x008bac56 in simplify_and_const_int (x=0x0, mode=DImode,
varop=0x2b2c79301190, constop=255)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:8247
#7 0x008bd00e in simplify_shift_const_1 (code=LSHIFTRT,
result_mode=DImode, varop=0x2b2c79301190, orig_count=56)
#8 0x008bd0e4 in simplify_shift_const (x=0x0, code=LSHIFTRT,
result_mode=DImode, varop=0x2b2c79300d60, count=56)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:9275
#9 0x008b44f3 in expand_compound_operation (x=0x2b2c79301180)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:5779
#10 0x008b7267 in force_to_mode (x=0x2b2c79301180, mode=DImode,
mask=18446744073709551615, just_select=0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:6910
#11 0x008b2969 in simplify_set (x=0x2b2c792fde20)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:5186
#12 0x008b127e in combine_simplify_rtx (x=0x2b2c792fde20,
op0_mode=VOIDmode, in_dest=0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:4800
#13 0x008af5ad in subst (x=0x2b2c792fde20, from=0x2b2c792fc020,
to=0x2b2c79300b60, in_dest=0, unique_copy=0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:4131
#14 0x008ae6b7 in subst (x=0x2b2c793010a0, from=0x2b2c792fc020,
to=0x2b2c79300b60, in_dest=0, unique_copy=0)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:4008
#15 0x008a9475 in try_combine (i3=0x2b2c792f99b0, i2=0x2b2c792f9960,
i1=0x2b2c792f9870, new_direct_jump_p=0x7fff31d5a7bc)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:2386
#16 0x008a50ef in combine_instructions (f=0x2b2c792d86c0, nregs=170)
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:845
#17 0x008c5138 in rest_of_handle_combine ()
at /space/rguenther/src/svn/gcc-4_2-branch/gcc/combine.c:12614
--
Summary: [4.2 Regresion] ICE in trunc_int_for_mode, at
explow.c:56 during combine
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug rtl-optimization/33148] [4.2 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-22 13:07 --- Created an attachment (id=14094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14094action=view) unreduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug rtl-optimization/33148] [4.2/4.3 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-22 13:07 --- trunk also fails (but only with the unreduced testcase). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regresion] ICE in |[4.2/4.3 Regresion] ICE in |trunc_int_for_mode, at |trunc_int_for_mode, at |explow.c:56 during combine |explow.c:56 during combine http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, rguenth at gcc dot gnu dot org wrote:
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
A5 array5;
A10 *ap;
void
f (void)
{
int ap;
{
extern IA *ap;
ap = array5;
}
}
The conclusion was it should be valid at least at compile time.
The real problem is that the frontend creates a conversion to (int[] *) rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
I think the C gimplifier should accept such assignments between compatible
types (not other pairs of types that can be assigned in C, just compatible
types) and generate whatever conversions are needed for valid GIMPLE at
that point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug tree-optimization/33145] Should combine float/int conversion and rounding functions
-- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-22 13:23:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33145
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-22 13:27 ---
Actually, to me this doesn't look like missed-optimization at all.
And you should be happy for 4.2.1 generated bigger code, 4.1.1 optimized out
something it shouldn't.
Below is an stripped down testcase, which works on 3.4/4.1/4.2/4.3 with -O0
or -O2 -fno-strict-aliasing, works even with -O2 with 3.4 and 4.2, segfaults
with 4.1 (x86_64 -m64, aborts with x86_64 -m32) and issues a bogus warning
about unitialized common_head and aborts on the trunk.
/* { dg-do run } */
/* { dg-options -O2 } */
typedef __SIZE_TYPE__ size_t;
extern void exit (int);
extern void *malloc (size_t);
extern void *realloc (void *, size_t);
extern void abort (void);
void *
__attribute__ ((noinline))
xmalloc (size_t size)
{
void *p = malloc (size);
if (p == 0)
exit (0);
return p;
}
void *
__attribute__ ((noinline))
xrealloc (void *old, size_t size)
{
void *p = realloc (old, size);
if (p == 0)
exit (0);
return p;
}
struct obj_section
{
unsigned int sh_type;
unsigned int sh_flags;
unsigned int sh_size;
unsigned int sh_addralign;
const char *name;
char *contents;
struct obj_section *load_next;
int idx;
};
struct obj_symbol
{
struct obj_symbol *next;
unsigned long value;
unsigned long size;
int secidx;
};
struct obj_file
{
unsigned short e_shnum;
struct obj_section **sections;
struct obj_symbol *symtab[521];
};
static void
__attribute__((noinline))
obj_allocate_commons (struct obj_file *f)
{
struct common_entry
{
struct common_entry *next;
struct obj_symbol *sym;
} *common_head = (void *) 0;
unsigned long i;
for (i = 0; i 521; ++i)
{
struct obj_symbol *sym;
for (sym = f-symtab[i]; sym; sym = sym-next)
if (sym-secidx == 0xfff2)
{
struct common_entry **p, *n;
for (p = common_head; *p; p = (*p)-next)
if (sym-size = (*p)-sym-size)
break;
n = __builtin_alloca (sizeof (*n));
n-next = *p;
n-sym = sym;
*p = n;
}
}
if (common_head)
{
for (i = 0; i f-e_shnum; ++i)
if (f-sections[i]-sh_type == 8)
break;
if (i == f-e_shnum)
{
struct obj_section *sec;
f-sections = xrealloc (f-sections, (i + 1) * sizeof (sec));
f-sections[i] = sec = xmalloc (sizeof (struct obj_section));
f-e_shnum = i + 1;
__builtin_memset (sec, 0, sizeof (*sec));
sec-sh_type = 1;
sec-sh_flags = (1 0) | (1 1);
sec-name = .bss;
sec-idx = i;
}
}
}
int
main (void)
{
struct obj_file of;
struct obj_symbol s;
struct obj_section *sec;
__builtin_memset (s, 0, sizeof (s));
s.value = 4;
s.size = 4;
s.secidx = 0xfff2;
__builtin_memset (of, 0, sizeof (of));
of.e_shnum = 2;
of.sections = xmalloc (2 * sizeof (sec));
of.sections[0] = sec = xmalloc (sizeof (struct obj_section));
__builtin_memset (sec, 0, sizeof (*sec));
sec-sh_type = 4;
sec-sh_flags = (1 0) | (1 1);
sec-name = .foo;
sec-idx = 0;
of.sections[1] = sec = xmalloc (sizeof (struct obj_section));
__builtin_memset (sec, 0, sizeof (*sec));
sec-sh_type = 4;
sec-sh_flags = (1 0) | (1 1);
sec-name = .bar;
sec-idx = 1;
of.symtab[0] = s;
obj_allocate_commons (of);
if (of.e_shnum != 3)
abort ();
return 0;
}
Even on the original testcase, obj_allocate_commons is so short because
the whole if (common_head) { ... } huge block has been completely optimized
out (watch for xrealloc call e.g.).
To me the code looks valid, there is no type puning involved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #9 from rguenther at suse dot de 2007-08-22 13:45 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote:
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12
---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
The real problem is that the frontend creates a conversion to (int[] *)
rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
I think the C gimplifier should accept such assignments between compatible
types (not other pairs of types that can be assigned in C, just compatible
types) and generate whatever conversions are needed for valid GIMPLE at
that point.
Ok, so when gimplifying a MODIFY_EXPR the following works:
gcc_assert (lang_hooks.types_compatible_p (TREE_TYPE (*to_p),
TREE_TYPE (*from_p)));
that is, as far as C is concerned, (int[] *) is convertible to (int[5] *).
Now, it is also convertible the other way around which is why
the conversion to (int[] *) is useless on the RHS -- but the conversion
from (int[10] *) to (int[5] *) is not useless, as they are not
compatible types as far as C is concerned.
So, strictly speaking, this special property of (int[] *) breaks
transitiveness of the useless_type_converison_p middle-end type-system
predicate.
We can fix things up in the gimplifier as you suggest by doing
(for gimplifying MODIFY_EXPR):
gcc_assert (lang_hooks.types_compatible_p (TREE_TYPE (*to_p),
TREE_TYPE (*from_p)));
STRIP_USELESS_TYPE_CONVERSION (*from_p);
if (!useless_type_conversion_p (TREE_TYPE (*to_p), TREE_TYPE (*from_p)))
*from_p = fold_convert (TREE_TYPE (*to_p), *from_p);
which in the case of this PR re-inserts (after stripping the cast
to (int[] *))
array10.0 = (int[5] *) array10;
ap = array10.0;
As far as I see we still need to re-instantiate transitiveness
of useless_type_converison_p somehow, by handling all of the
aggregate type compatibilities in the middle-end without dispatching
back to the frontends. Like with something like
Index: tree-ssa.c
===
--- tree-ssa.c (revision 127700)
+++ tree-ssa.c (working copy)
@@ -1019,6 +1019,31 @@ useless_type_conversion_p (tree outer_ty
return useless_type_conversion_p (TREE_TYPE (outer_type),
TREE_TYPE (inner_type));
+ /* For array types we have to consider element types and array domain. */
+ else if (TREE_CODE (inner_type) == ARRAY_TYPE
+ TREE_CODE (outer_type) == ARRAY_TYPE)
+{
+ /* If the element types are not trivially convertible, the
+arrays are not compatible. */
+ if (!useless_type_conversion_p (TREE_TYPE (outer_type),
+ TREE_TYPE (inner_type)))
+ return false;
+
+ /* A conversion to an unknown domain is useless. */
+ if (!TYPE_DOMAIN (outer_type))
+ return true;
+
+ /* Likewise a conversion to a equal domain. */
+ if (TYPE_DOMAIN (outer_type)
+ TYPE_DOMAIN (inner_type))
+ return (operand_equal_p (TYPE_MIN_VALUE (TYPE_DOMAIN (outer_type)),
+TYPE_MIN_VALUE (TYPE_DOMAIN (inner_type)), 0)
+operand_equal_p (TYPE_MAX_VALUE (TYPE_DOMAIN (outer_type)),
+ TYPE_MAX_VALUE (TYPE_DOMAIN (inner_type)),
0));
+
+ return false;
+}
+
/* For aggregates we may need to fall back to structural equality
checks. */
else if (AGGREGATE_TYPE_P (inner_type)
still this would need fixing up the types during gimplification as
int[5] * = (int[] *)int[10];
with the patch above lacks the cast to (int[5] *).
I see that Honza is thinking of a type merging/fixup pass anyway, but
I wonder if the frontend is really unfixable here (supposedly the
proposed fixup to the gimplifier above could be done in the gimplify_expr
langhook as well, to not pessimize other frontends).
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-22 13:54 ---
Even shorter testcase:
/* { dg-do run } */
/* { dg-options -O2 } */
extern void abort (void);
struct S
{
struct S *a;
int b;
};
#ifdef VAR
struct S t;
#endif
int
main (void)
{
struct S *s = (struct S *) 0, **p, *n;
for (p = s; *p; p = (*p)-a);
n = (struct S *) __builtin_alloca (sizeof (*n));
n-a = *p;
n-b = 1;
*p = n;
if (!s)
abort ();
return 0;
}
This one behaves identically with 4.1/4.2/trunk, -O2 -UVAR - abort,
-O2 -DVAR - success, -O2 -fno-strict-aliasing -UVAR - success.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #9 from jakub at gcc dot gnu dot org 2007-08-22 13:56 --- When struct S is not defined at global scope, but within main, then no matter if struct S t; is present or not 4.1/4.2/trunk aborts with -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-22 14:19 --- Probably related to some of the open alias issues of 4.1: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=4.1target_milestone=4.1.3target_milestone=4.1.4known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=wrong-code%2C+aliasbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timequery_based_on=4.1+blockerfield0-0-0=nooptype0-0-0=noopvalue0-0-0= -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #11 from jakub at gcc dot gnu dot org 2007-08-22 14:29 --- Yeah, PR30708 seems to be stripped down from the same source. But the stripped down testcase here in c#8 is 4.1/4.2/4.3 regression, not just 4.1 regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug fortran/31675] Fortran front-end and libgfortran should have a common header file
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-23 22:40:05 |2007-08-22 14:40:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31675
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 14:41 ---
Note: for a(:) and thus also for p=a(:) the lbound starts at 1 (this is
somewhere hidden in 6.2.2.3 Array sections) - this part works.
Partial patch. Note: This patch is incomplete as one also needs to set the
offset to 10.
--- trans-array.c (revision 127689)
+++ trans-array.c (working copy)
@@ -4766,6 +4766,4 @@ gfc_conv_expr_descriptor (gfc_se * se, g
- /* If we have an array section or are assigning to a pointer,
-make sure that the lower bound is 1. References to the full
-array should otherwise keep the original bounds. */
- if ((!info-ref
- || info-ref-u.ar.type != AR_FULL
- || se-direct_byref)
+ /* If we have an array section make sure that the lower bound is 1.
+References to the full array should otherwise keep the original
+bounds. */
+ if ((!info-ref || info-ref-u.ar.type != AR_FULL)
! { dg-do run }
!
! PR fortran/33139
!
program prog
implicit none
real, target :: a(-10:10)
real, pointer :: p(:)
integer :: i
do i = -10, 10
a(i) = real(i)
end do
p = a
if(lbound(p,dim=1) /= -10 .and. ubound(p,dim=1) /= 10)
call abort()
do i = -10, 10
if(p(i) /= real(i)) call abort()
end do
p = a(:)
if(lbound(p,dim=1) /= 1 .and. ubound(p,dim=1) /= 21)
call abort()
end program prog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #10 from joseph at codesourcery dot com 2007-08-22 14:52 --- Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, rguenther at suse dot de wrote: As far as I see we still need to re-instantiate transitiveness of useless_type_converison_p somehow, by handling all of the aggregate type compatibilities in the middle-end without dispatching back to the frontends. Like with something like Arrays aren't the only case where C type compatibility isn't transitive. For example, two enums compatible with the same integer type aren't compatible with each other. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #11 from rguenther at suse dot de 2007-08-22 15:03 --- Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote: Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, rguenther at suse dot de wrote: As far as I see we still need to re-instantiate transitiveness of useless_type_converison_p somehow, by handling all of the aggregate type compatibilities in the middle-end without dispatching back to the frontends. Like with something like Arrays aren't the only case where C type compatibility isn't transitive. For example, two enums compatible with the same integer type aren't compatible with each other. They are as far as the middle-end is concerned, so this is a non-issue there. The issue is really that for all aggregate types we still ask the frontend via the langhook for middle-end type compatibility. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-22 15:15 --- Indeed. bb 2: # s_13 = VDEF s_12(D) s = 0B; goto bb 4; bb 4: # p_1 = PHI s(2), p_5(3) # VUSE HEAP.5_14(D), SMT.7_15(D) D.2019_3 = *p_1; is wrong alias info (from trunk salias dump). The load from *p_1 misses a use of s_13 - or the assignment to s should use SMT.7 instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords|missed-optimization |alias, wrong-code Summary|[4.2/4.3 Regression] -Os|[4.1/4.2/4.3 Regression] -Os |generated code grew almost |generated code grew almost |twice 4.2.1 versus 4.1.1|twice 4.2.1 versus 4.1.1 Target Milestone|4.2.2 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug rtl-optimization/33148] [4.2/4.3 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-22 15:44 --- (In reply to comment #5) Created an attachment (id=13789) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit] preprocessed testcase :-( I cannot compile this testcase [EMAIL PROTECTED]:~/gcc$ g++ -c -O1 -Wall pr32395.ii -Wfatal-errors /usr/include/c++/4.2.0/x86_64-pld-linux/bits/c++config.h:149: error: expected `=' before __attribute__ [EMAIL PROTECTED]:~/gcc$ gcc -v 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 (Ubuntu 4.1.2-0ubuntu4) -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-22 15:52 --- But not with 4.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|4.2.0 4.3.0 |4.2.0 4.2.1 Known to work|4.1.2 |4.1.2 4.3.0 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-08-22 15:52 --- At least for 4.3, ipa-type-escape is not looking into phi_nodes for address taking, so we end up returning false for may_alias_p (p, s) because we believe nobody ever takes the address of s. IE if (ipa_type_escape_field_does_not_clobber_p (var_type, TREE_TYPE (ptr))) incorrectly returns true. ipa-type-escape.c needs to be changed to scan refs in phi_nodes (it was written when we had just plain old gimple during IPA) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #7 from pluto at agmk dot net 2007-08-22 15:54 --- (In reply to comment #6) (In reply to comment #5) Created an attachment (id=13789) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit] preprocessed testcase :-( I cannot compile this testcase it works with my gcc-4.2.1-20070719. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-22 16:20 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:53:49 |2007-08-22 16:20:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug fortran/33149] New: internal compiler error: in gfc_conv_constant
GCC Version: gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux) OS: Linux s24n160 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686 i686 i386 GNU/Linux Command-line gfortran -c -Wall -Wsurprising -I../lib.f/ ../lib.f/bomec_func.f95 -o ../lib.f/bomec_func.o Error message: ../lib.f/bomec_func.f95: In function get_cand: ../lib.f/bomec_func.f95:5: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:348 bomec_func.f95 and omec_globals: module bomec_func use omec_globals implicit none contains function bomec_step(fm,old,new,ncl,ppart,psub) implicit none integer, intent(IN) :: ppart(:,:) real(sng) :: bomec_step,maxgain=0.0 real(sng),intent(IN) :: fm(:,:) integer, intent(IN) :: old(:,:) integer, intent(OUT) :: new(:,:) integer :: psub(:,:),lenps,lenew=0 integer :: ncl,i do i=1,ncl call get_psub(old(i,:),ppart,psub,lenps) call get_cand(fm,old(i,:),maxgain,psub,lenps,new,lenew) enddo bomec_step = maxgain end function bomec_step subroutine get_ppart(fm,ppart) implicit none real(sng), intent(IN) :: fm(:,:) real(sng), intent(OUT) :: ppart(:,:) integer :: shp(2),i,j,cnt,lenppart,ndim shp = shape(fm) ndim = shp(1) cnt = 1 do i = 1,ndim-1 do j = i+1,ndim if (fm(i,j) .gt. 0.0) then ppart(cnt,:) = (/i,j/) cnt=cnt+1 endif end do end do end subroutine get_ppart subroutine get_psub(cl,ppart,psub,lenps) integer, intent(IN) :: cl(:),ppart(:,:) integer, intent(OUT) :: psub(:,:),lenps integer :: npos,i npos = size(ppart)/2 lenps=0 psub=0 do i=1,npos if (cl(ppart(i,1)) /= cl(ppart(i,2))) then lenps=lenps+1 psub(lenps,:)=ppart(i,:) endif enddo end subroutine get_psub subroutine get_cand(fm,cl,maxgain,psub,lenps,new,lenew) integer, intent(IN) :: cl(:),psub(:,:),lenps integer, intent(INOUT) :: new(:,:),lenew real(sng), intent(IN) :: fm(:,:) real(sng), intent(INOUT) :: maxgain real(sng) :: gain integer :: i,j,k,ndim=size(cl) do i=1,lenps gain = 0.0 do j=1,ndim-1 do k=j+1,ndim ! if (cl(j)==psub(i,1) .and. cl(k)==psub(i,2) .or. ! cl(j)==psub(i,2) .and. cl(k)==psub(i,1)) gain=gain+fm(j,k) end do end do enddo end subroutine get_cand end module bomec_func module omec_globals integer, parameter :: dbl=kind(0d0),sng=kind(0.0) logical :: done = .false. end module omec_globals -- Summary: internal compiler error: in gfc_conv_constant Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hirmic at web dot de GCC host triplet: 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33149
[Bug fortran/33149] internal compiler error: in gfc_conv_constant
--- Comment #1 from hirmic at web dot de 2007-08-22 16:46 --- The error is caused by this line of subroutine get_cand: integer :: i,j,k,ndim=size(cl) if it is replaced by integer :: i,j,k,ndim ndim=size(cl) then the error doesn't occur. -- hirmic at web dot de changed: What|Removed |Added Summary|internal compiler error: in |internal compiler error: in |gfc_conv_constant |gfc_conv_constant http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33149
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-22 16:47 --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) Created an attachment (id=13789) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit] preprocessed testcase :-( I cannot compile this testcase it works with my gcc-4.2.1-20070719. Perhaps is because my target is i*86-linux-gnu? Could you reprocess it for that, please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug tree-optimization/32759] False claim of that xyz is used uninitialized
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-22 16:49 --- Basically, when we reach diff = xlimit; we don't know that xlimit must be initialized. This may end up in different scenarios depending on the SSA tree finally generated. In any of those scenarios, not warning is sheer luck. If you remove the assignment to diff, still when we reach ang ? xlimit : 0.0; we don't know that xlimit is always initialized. We get the may be because we don't know the value of ang, so xlimit may not be used at all. Finally, I guess that using constants make the warning disappear because the constant-propagation pass assumes that the uninitialized value of xlimit is either of the constants and thus xlimit is never used uninitialized. My conclusion here is that we should not get a is uninitialized. Maybe we can use the fact that the block is not entered 100% of times to avoid saying is used? Nonetheless, avoiding the warning completely depends on being able to avoid a default case for the switch (which is a missed-optimization in VRP and not a diagnostics problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32759
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- Comment #3 from eweddington at cso dot atmel dot com 2007-08-22 16:57 --- Wouter, please attach the assembly output that you are getting for your test.c file using 4.1.2. That way we can compare it to other compiler versions. Thanks, Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug target/33050] [avr] unnessary register save
--- Comment #2 from eweddington at cso dot atmel dot com 2007-08-22 17:09 --- 4.3.0 20070817 snapshot generates this for the testcase: test2: push r16 push r17 /* prologue: function */ /* frame size = 0 */ mov r16,r24 ldi r24,lo8(10) call foo mov r17,r24 ldi r24,lo8(10) call foo mov r24,r16 add r24,r17 /* epilogue start */ pop r17 pop r16 ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33050
[Bug middle-end/20968] Spurious may be used uninitialized warning
--- Comment #5 from manu at gcc dot gnu dot org 2007-08-22 17:14 --- (In reply to comment #4) Just an interesting tidbit. This testcase exposes a much more difficult/interesting long term problem. Namely, how should we handle uninitialized warnings for variables which are exposed by optimization. I think the problem reduces to what we do when we are unsure? Currently we mostly warn except for CCP merging undefined values with constants and when the address of the variable is passed to a function. If the body is not taken into account (because it is not inlined) we assume that baz() initializes i. When inlined, we are not sure anymore, so we warn. This will happen whenever more optimisation turns the balance from unsure but not warn to unsure but warn. In the general case, I don't think this can be solved unless we always warn or we always don't warn when unsure. Therefore, the only thing we could do is handle the inlined version as well as Andrew's testcase in comment #2. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968
[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #5 from eweddington at cso dot atmel dot com 2007-08-22 17:16 --- Confirmed on the AVR target for 4.3.0 20070817 snapshot. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.3.0 Known to work||3.4.4 Last reconfirmed|-00-00 00:00:00 |2007-08-22 17:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #31 from jason at gcc dot gnu dot org 2007-08-22 17:23 --- Subject: Bug 29365 Author: jason Date: Wed Aug 22 17:23:37 2007 New Revision: 127711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127711 Log: PR c++/29365 * pt.c (outermost_tinst_level): New function. * lex.c (in_main_input_context): New function. * decl2.c (constrain_class_visibility): Use it to avoid warning about uses of the anonymous namespace in the main input file. Added: trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-3.C trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-3.h Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/lex.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-1.C trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #14 from jakub at gcc dot gnu dot org 2007-08-22 17:24 ---
--- ipa-type-escape.c.jj13 2007-08-13 15:11:18.0 +0200
+++ ipa-type-escape.c 2007-08-22 19:21:07.0 +0200
@@ -1704,6 +1704,21 @@ analyze_function (struct cgraph_node *fn
FOR_EACH_BB_FN (this_block, this_cfun)
{
block_stmt_iterator bsi;
+ tree phi, op;
+ use_operand_p use;
+ ssa_op_iter iter;
+
+ /* Find the addresses taken in phi node arguments. */
+ for (phi = phi_nodes (this_block); phi; phi = PHI_CHAIN (phi))
+ {
+ FOR_EACH_PHI_ARG (use, phi, iter, SSA_OP_USE)
+ {
+ op = USE_FROM_PTR (use);
+ if (TREE_CODE (op) == ADDR_EXPR)
+ check_rhs_var (op);
+ }
+ }
+
for (bsi = bsi_start (this_block); !bsi_end_p (bsi); bsi_next (bsi))
walk_tree (bsi_stmt_ptr (bsi), scan_for_refs,
fn, visited_nodes);
doesn't help here at all (it could have helped if one of the PHI arguments
contained say s.some_field, but as it contains just s, it doesn't do
anything.
mark_interesting_addressof is only called for addresses of aggr fields
and has_proper_scope_for_analysis is a nop for automatic variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug fortran/33149] internal compiler error: in gfc_conv_constant
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-22 17:35 --- I think the problem has been fixed meanwhile; I can reproduce it with 4.1.3 20070521 and 4.2.1 20070705, but not with 4.3.0 20070822. Using gfortran 4.3 gives the following error message: integer :: i,j,k,ndim=size(cl) 1 Error: deferred array 'cl' at (1) is not permitted in an initialization expression It probably works with gfortran 4.2 if you fix the code. The official GCC policy is to only fix regressions in released versions - and as this seems to be an ICE which only occurs for invalid code, it is unlikely that we will break that rule. gfortran 4.3 nightly binaries are available from http://gcc.gnu.org/wiki/GFortranBinaries and older gcc 4.3 openSUSE builds are available from http://software.opensuse.org/search?q=gcc43p=1baseproject=openSUSE%3A10.2 (I selected 10.2, if you have to modify the search if you have another version of SUSE; see also: http://gcc.gnu.org/wiki/GFortranDistros ) Please confirm that either with the 4.3 binaries or after fixing your program, error is gone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33149
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-22 17:38 --- (In reply to comment #6) (In reply to comment #5) gcc version 4.1.0 20051106 (experimental) ../t6.c: In function foo: ../t6.c:13: warning: j is used uninitialized in this function Despite what I said before, for this particular case, we should never give a is used warning if the BB is not executed with 100% probability. Hmm, I'll check whether we can detect this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug fortran/33149] [4.1 and 4.2 only] internal compiler error: in gfc_conv_constant
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 17:46 --- The error is caused by this line of subroutine get_cand: integer :: i,j,k,ndim=size(cl) if it is replaced by integer :: i,j,k,ndim ndim=size(cl) then the error doesn't occur. Note: The first version implies SAVE, i.e. ndim is set only once to size(cl) and remains unchanged when you call the procedure the next time. This can be used for, e.g., logical, SAVE :: first_run = .true. if (first_run) print *, First Run first_run = .false. In order that this works one needs to have an initialization expression. In the second case, SAVE is not implied and you have a normal variable. Note: This is different from C where both versions are doing the same. The SAVE equivalent in C is static. As it works using the right syntax and it is properly diagnosed with gfortran 4.3, I close it as WONTFIX. If you really believe it should be fixed in 4.2, please reopen. PS: Thanks for the bug report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.2.1 4.1.3 Known to work||4.3.0 Resolution||WONTFIX Summary|internal compiler error: in |[4.1 and 4.2 only] internal |gfc_conv_constant |compiler error: in ||gfc_conv_constant http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33149
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-22 17:48 --- The warning is not emitted any more in GCC 4.1.2 and I am fairly sure that this case is covered by gcc.dg/uninit-5.c and gcc.dg/uninit-9.c, so I am tempted to close this as fixed. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug target/17993] Error in dwarf2 debug output of bitfield members
--- Comment #3 from eweddington at cso dot atmel dot com 2007-08-22 17:48 --- Bug fixed in 4.3.0 20070817 snapshot. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Comment #18 from burnus at gcc dot gnu dot org 2007-08-22 18:07 --- so I am tempted to close this as fixed. At least PR 27289 and PR 29479 (marked as duplicate of this PR) seem still to show the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #9 from pluto at agmk dot net 2007-08-22 18:36 --- Created an attachment (id=14095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14095action=view) preprocessed testcase for 32-bits targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Comment #19 from manu at gcc dot gnu dot org 2007-08-22 18:47 --- (In reply to comment #18) so I am tempted to close this as fixed. At least PR 27289 and PR 29479 (marked as duplicate of this PR) seem still to show the bug. They shouldn't be duplicates then. Here, the warning does not show up because CCP is assuming that the uninitialized value of b is 10. Thus, the return value is either 10 or 0 but never uninitialized. PR29479 seems a duplicate of PR27289 (the latter seems a reduced testcase of the former). The warning shows up because: 1) SRA generates a PHI node that contains the uninitialized value 2) CCP is not working here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug c++/33150] New: frend functions of template get new diagnostic
The following code received no diagnostic in 4.0.1, but on 4.2.1 gets:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In instantiation of 'foo2int':
foo.cc:16: instantiated from here
foo.cc:12: error: redefinition of 'void bar(int)'
foo.cc:5: error: 'void bar(int)' previously defined here
Test case:
templatetypename T
class foo1 {
public:
friend
voidbar(T t) {};
};
templatetypename T
class foo2 {
public:
friend
voidbar(T t) {};
};
foo1int f1;
foo2int f2;
int main() {}
This may just be a result of tightening up gcc to the standard and the code
always was wrong, but I submit the report in case it is actually a regression
in a rarely-used part of the language.
As I understand it, every function defined in a template is considered to
itself be a template, and hence having a template function that is also a
definition does not count as a duplicate definition no matter how many times
the template is instantiated. However, that seems to no longer apply for
friends declared and defined in templates. Note that both friends refer to the
same function, which is textually declared identically.
Incidentally, declaring the friends inline makes no difference to the
diagnostic, whereas it would for a plain function. Possibly the construction
does in fact reflect the standard, but the inline keyword is mishandled? I
leave to the language lawyers whether this is valid or a regression, but in any
case you might want to add this code to your regression suite.
--
Summary: frend functions of template get new diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33150
[Bug c++/19809] [4.0/4.1 Regression] Multiple definitions of friend functions in template classes
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-08-22 19:06 --- *** Bug 33150 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/33150] frend functions of template get new diagnostic
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 19:06 --- Yes and 3.3.x used to produce an error message so this was a regression in 4.0.1 but fixed in 4.0.4, see PR 19809. *** This bug has been marked as a duplicate of 19809 *** -- 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=33150
[Bug target/33147] ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -mhard-float -O
--- Comment #1 from martinwguy at yahoo dot it 2007-08-22 19:25 --- Also present in gcc version 4.2.1 (Debian 4.2.1-4) native compiler on arm-linux-gnueabi This bug was originally shown up by three files in lame-3.97; this is the smallest code that reproduces it. -- martinwguy at yahoo dot it changed: What|Removed |Added CC||martinwguy at yahoo dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33147
[Bug rtl-optimization/11832] Optimization of common code in switch statements
--- Comment #4 from aldot at gcc dot gnu dot org 2007-08-22 20:07 --- I'll try to find the time to thing about VN / PRE. Thanks, stevenb, for your comment. Please feel free to ping or take this if i time out (as usual).. -- aldot at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aldot at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #15 from dberlin at gcc dot gnu dot org 2007-08-22 20:10
---
(In reply to comment #14)
--- ipa-type-escape.c.jj13 2007-08-13 15:11:18.0 +0200
+++ ipa-type-escape.c 2007-08-22 19:21:07.0 +0200
@@ -1704,6 +1704,21 @@ analyze_function (struct cgraph_node *fn
FOR_EACH_BB_FN (this_block, this_cfun)
{
block_stmt_iterator bsi;
+ tree phi, op;
+ use_operand_p use;
+ ssa_op_iter iter;
+
+ /* Find the addresses taken in phi node arguments. */
+ for (phi = phi_nodes (this_block); phi; phi = PHI_CHAIN (phi))
+ {
+ FOR_EACH_PHI_ARG (use, phi, iter, SSA_OP_USE)
+ {
+ op = USE_FROM_PTR (use);
+ if (TREE_CODE (op) == ADDR_EXPR)
+ check_rhs_var (op);
+ }
+ }
+
for (bsi = bsi_start (this_block); !bsi_end_p (bsi); bsi_next (bsi))
walk_tree (bsi_stmt_ptr (bsi), scan_for_refs,
fn, visited_nodes);
doesn't help here at all (it could have helped if one of the PHI arguments
contained say s.some_field, but as it contains just s, it doesn't do
anything.
mark_interesting_addressof is only called for addresses of aggr fields
and has_proper_scope_for_analysis is a nop for automatic variables.
Sigh. It should be considering s to be an address taking of the first field.
Looks like look_for_address_of needs to be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug middle-end/32269] [4.3 Regression] 403.gcc miscompiled
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-22 20:17 --- works again, closing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32269
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-22 20:23
---
Note alias info is correct:
# signInfo_2 = VDEF signInfo_1(D)
signInfo = {};
# signInfo_3 = VDEF signInfo_2
signInfo.a = 16;
# signInfo_4 = VDEF signInfo_3
signInfo.b = 1;
# signInfo_5 = VDEF signInfo_4
signInfo.c = 0;
but somehow DSE figures that the a/b/c inits do a def killing the initial one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-22 20:25 --- Or more like, the use on the call is missed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 20:37 ---
Looks ok on current trunk - after einline:
setparam ()
{
char * * D.2024;
char * D.2025;
char * * ap;
struct shparam * shellparam.0;
bb 2:
shellparam.0_1 = shellparam;
ap_2 ={v} shellparam.0_1-p;
goto bb 4;
bb 3:
D.2024_3 ={v} shellparam.0_1-p;
free (D.2024_3);
ap_4 = ap_5 + 8;
bb 4:
# ap_5 = PHI ap_2(2), ap_4(3)
D.2025_6 = *ap_5;
if (D.2025_6 != 0B)
goto bb 3;
else
goto bb 5;
bb 5:
return;
}
and even final_cleanup has
setparam ()
{
char * * D.2024;
char * * ap;
bb 2:
ap ={v} shellparam.p;
if (*ap != 0B)
goto bb 3;
else
goto bb 4;
bb 3:
D.2024 ={v} shellparam.p;
free (D.2024);
ap = ap + 8;
if (MEM[base: ap] != 0B)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
I suppose
2007-07-13 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/32721
* tree-ssa-ccp.c (maybe_fold_stmt_indirect): Preserve
TREE_THIS_VOLATILE on the folded reference.
* tree-ssa-operands.c (get_expr_operands): Set has_volatile_ops
if the array reference has TREE_THIS_VOLATILE set.
fixed this for real.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||32721
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #32 from jason at gcc dot gnu dot org 2007-08-22 20:40 --- Subject: Bug 29365 Author: jason Date: Wed Aug 22 20:40:30 2007 New Revision: 127716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127716 Log: PR c++/29365 * pt.c (outermost_tinst_level): New function. * lex.c (in_main_input_context): New function. * decl2.c (constrain_class_visibility): Use it to avoid warning about uses of the anonymous namespace in the main input file. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/decl2.c branches/gcc-4_2-branch/gcc/cp/lex.c branches/gcc-4_2-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug libfortran/31546] add --enable-intermodule
--- Comment #5 from aldot at gcc dot gnu dot org 2007-08-22 20:53 --- Created an attachment (id=14096) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14096action=view) add enable-intermodule for libgfortran against r127717 Updated patch to allow for configuring libgfortran with ./configure --enable-intermodule optimization -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #13367|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 21:28 --- Subject: Bug 33020 Author: burnus Date: Wed Aug 22 21:28:08 2007 New Revision: 127719 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127719 Log: 2007-08-22 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33020 * resolve.c (gfc_iso_c_sub_interface): Remove setting of type and kind for optional SHAPE parameter of C_F_POINTER. 2007-08-22 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33020 * gfortran.dg/c_f_pointer_shape_tests_2.f03: Update test to include multiple kinds for SHAPE parameter within a single namespace. * gfortran.dg/c_f_pointer_shape_tests_2_driver.c: Ditto. * gfortran.dg/c_f_pointer_shape_tests_3.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_3.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2_driver.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug tree-optimization/32949] suboptimal address generation for int indices on 64-bit targets
--- Comment #3 from amonakov at gmail dot com 2007-08-22 21:29 --- With first hunk modified not to delete 'return true', this patch passes bootstrap with all default languages on ia64 and x86_64 with --disable-multilib, and passes regtest with no new regressions (all said with 10-days-old trunk, revision 127475). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32949
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-22 21:29 --- FIXED on the trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #33 from jason at gcc dot gnu dot org 2007-08-22 21:50 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug rtl-optimization/33151] New: Invalid insn with pre_inc
I'm hitting the following on 6 SPEC CPU2006 benchmarks, some with pre_inc
others with pre_modify.
run/build_base_gcc411-base.0001 cat junk.c
extern double cos (double x);
extern double sin (double x);
double
pre_inc_ice (int n)
{
int i;
double sc, ss, arg;
sc = ss = 0.0;
for (i = 0; i n; i++)
{
arg = 1.0 / n;
sc += cos (arg);
ss += sin (arg);
}
return sc + ss;
}
run/build_base_gcc411-base.0001 /opt/biarch/gcc433-xlc-perf-2/bin/gcc -S -m32
-O2 junk.c
junk.c: In function 'pre_inc_ice':
junk.c:18: error: unrecognizable insn:
(insn 84 80 85 4 junk.c:11 (set (reg/f:SI 155)
(pre_inc:SI (reg/f:SI 139))) -1 (expr_list:REG_INC (reg/f:SI 139)
(nil)))
junk.c:18: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: Invalid insn with pre_inc
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug target/33151] Invalid insn with pre_inc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 22:32 ---
The splitting of:
(insn 22 80 24 4 t.c:11 (parallel [
(set (reg:DF 123 [ pretmp.23 ])
(float:DF (reg/v:SI 128 [ n ])))
(use (reg:SI 132))
(use (reg:DF 133))
(clobber (mem/c/i:DF (pre_inc:SI (reg/f:SI 139)) [2 S8 A64]))
(clobber (reg:DF 137))
(clobber (reg:SI 138))
]) 244 {*floatsidf2_internal} (expr_list:REG_DEAD (reg:DF 133)
(expr_list:REG_DEAD (reg:SI 132)
(expr_list:REG_UNUSED (reg:SI 138)
(expr_list:REG_UNUSED (reg:DF 137)
(expr_list:REG_INC (reg/f:SI 139)
(expr_list:REG_EQUAL (float:DF (reg/v:SI 128 [ n ]))
(nil
Causes the invalid pre_inc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|rtl-optimization|target
Ever Confirmed|0 |1
GCC build triplet|powerpc64-linux |
GCC host triplet|powerpc64-linux |
GCC target triplet|powerpc64-linux |powerpc-linux-gnu
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-08-22 22:32:28
date||
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug fortran/33152] New: Initialization/declaration problems in block data
The following four variants of declarations have been tried in a block data statement with gfortran 4.1.3 and partly also with 4.3.0: Var. 1: character(len=3) :: emname(nmin)=(/'bar','baz'/) common/nmstr/emname gives this error: In file test.f90:16 common/nmstr/emname 1 Error: Previously initialized symbol 'emname' in COMMON block 'nmstr' at (1) Var. 2: common/nmstr/emname character(len=3) :: emname(nmin)=(/'bar','baz'/) gives this error: In file test.f90:19 character(len=3) :: emname(nmin)=(/'bar','baz'/) 1 Error: Initializer not allowed for COMMON variable 'emname' at (1) In file test.f90:16 common/nmstr/emname 1 Error: Symbol 'emname' at (1) has no IMPLICIT type Var. 3: common/nmstr/emname data emname/'bar','baz'/ character(len=3) :: emname(nmin) gives this error: test.f90:1: internal compiler error: in check_data_variable, at fortran/resolve.c:5865 Please submit a full bug report, with preprocessed source if appropriate. Var. 4: character(len=3) :: emname(nmin) !=(/'bar','baz'/) common/nmstr/emname data emname/'bar','baz'/ works. My question is this: I thought all four variants are compliant with the standard. Which ones are possibly not, and where does gfortran indeed have a bug? Var. 1 worked with the Intel compiler; I didn't/can't test the others. The complete test program is below (comment/uncomment some lines as applicable). My system is SUSE Linux 10.2. program foo implicit none integer, parameter :: nmin=2 double precision :: rho0(nmin) common/phasedat/rho0 end program foo block data thdinit implicit none integer, parameter :: nmin=2 !double precision :: rho0(nmin) common/phasedat/rho0 double precision :: rho0(nmin) character(len=3) :: emname(nmin) !=(/'bar','baz'/) common/nmstr/emname data emname/'bar','baz'/ !character(len=3) :: emname(nmin)=(/'bar','baz'/) end block data thdinit -- Summary: Initialization/declaration problems in block data Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ruedas at dtm dot ciw dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33152
[Bug target/33151] Invalid insn with pre_inc
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-22 22:39 ---
What the auto pre-increment pass is doing looks ok from the point of view of
correct RTL.
Before:
(insn 22 21 70 4 t.c:11 (parallel [
(set (reg:DF 123 [ pretmp.23 ])
(float:DF (reg/v:SI 128 [ n ])))
(use (reg:SI 132))
(use (reg:DF 133))
(clobber (mem/c/i:DF (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [2 S8 A64]))
(clobber (reg:DF 137))
(clobber (reg:SI 138))
]) 244 {*floatsidf2_internal} (expr_list:REG_DEAD (reg:DF 133)
(expr_list:REG_DEAD (reg:SI 132)
(expr_list:REG_UNUSED (reg:SI 138)
(expr_list:REG_UNUSED (reg:DF 137)
(expr_list:REG_EQUAL (float:DF (reg/v:SI 128 [ n ]))
(nil)))
(insn 70 22 24 4 t.c:6 (set (reg/f:SI 139)
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8]))) 79 {*addsi3_internal1} (nil))
After:
(insn 80 21 22 4 t.c:11 (set (reg/f:SI 139)
(reg/f:SI 113 sfp)) -1 (nil))
(insn 22 80 24 4 t.c:11 (parallel [
(set (reg:DF 123 [ pretmp.23 ])
(float:DF (reg/v:SI 128 [ n ])))
(use (reg:SI 132))
(use (reg:DF 133))
(clobber (mem/c/i:DF (pre_inc:SI (reg/f:SI 139)) [2 S8 A64]))
(clobber (reg:DF 137))
(clobber (reg:SI 138))
]) 244 {*floatsidf2_internal} (expr_list:REG_INC (reg/f:SI 139)
(expr_list:REG_DEAD (reg:DF 133)
(expr_list:REG_DEAD (reg:SI 132)
(expr_list:REG_UNUSED (reg:SI 138)
(expr_list:REG_UNUSED (reg:DF 137)
(expr_list:REG_EQUAL (float:DF (reg/v:SI 128 [ n ]))
(nil
The semantics have not changed but we get an pre_inc inside the clobber now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug target/33151] Invalid insn with pre_inc
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-22 22:41 --- I think we need a new predicate for this rtl instruction, currently we just have: (clobber (match_operand:DF 4 memory_operand =o)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug tree-optimization/32949] suboptimal address generation for int indices on 64-bit targets
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-08-22 23:05 --- Subject: Bug 32949 Author: rakdver Date: Wed Aug 22 23:05:05 2007 New Revision: 127720 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127720 Log: 2007-08-22 Zdenek Dvorak [EMAIL PROTECTED] PR tree-optimization/32949 * tree-ssa-loop-niter.c (scev_probably_wraps_p): Test nowrap_type_p before failing for ivs with non-constant step. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32949
[Bug c/32643] [4.3 Regression] Wrong error message with unsigned char a = uchar512
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug testsuite/33153] New: FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c -O2 -fno-show-column -lm -o ./pr32912-1.exe(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) f or a exceeds maximum alignment for global common data. Using 8^M /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) for b exceeds maximum alignment for global common data. Using 8^M /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) for c exceeds maximum alignment for global common data. Using 8^M /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) f or d exceeds maximum alignment for global common data. Using 8^M /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) for e exceeds maximum alignment for global common data. Using 8^M /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16) f or f exceeds maximum alignment for global common data. Using 8^M -- Summary: FAIL: gcc.dg/pr32912-[12].c (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-hpux* GCC host triplet: hppa*-*-hpux* GCC target triplet: hppa*-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 23:38 --- The warning comes from: typedef int __m128i __attribute__ ((__vector_size__ (16))); __m128i a, b, c, d, e, f; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-22 23:39 --- Subject: Re: FAIL: gcc.dg/pr32912-[12].c (test for excess errors) The warning comes from: typedef int __m128i __attribute__ ((__vector_size__ (16))); __m128i a, b, c, d, e, f; Right. Would it be ok to make this declaration static? That will avoid the warning. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
Re: [Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
On 22 Aug 2007 23:39:50 -, dave at hiauly1 dot hia dot nrc dot ca [EMAIL PROTECTED] wrote: Right. Would it be ok to make this declaration static? That will avoid the warning. I think in this case, yes. Thanks, Andrew Pinski
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #3 from pinskia at gmail dot com 2007-08-22 23:42 --- Subject: Re: FAIL: gcc.dg/pr32912-[12].c (test for excess errors) On 22 Aug 2007 23:39:50 -, dave at hiauly1 dot hia dot nrc dot ca [EMAIL PROTECTED] wrote: Right. Would it be ok to make this declaration static? That will avoid the warning. I think in this case, yes. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug middle-end/33154] New: FAIL: gcc.c-torture/execute/20010119-1.c compilation, -Os
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20010119-1.c -w -Os -fno-s how-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/20010119-1.x7 (ti meout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: foo (first referenced in /var/tmp//ccUSmh7j.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/ccs/bin/ld: Unsatisfied symbols: foo (first referenced in /var/tmp//ccUSmh7j.o) (code) collect2: ld returned 1 exit status FAIL: gcc.c-torture/execute/20010119-1.c compilation, -Os UNRESOLVED: gcc.c-torture/execute/20010119-1.c execution, -Os This is the assembly code generated on hppa2.0w-hp-hpux11.11: # less 20010119-1.s .LEVEL 1.1 .SPACE $PRIVATE$ .SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31 .SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82 .SPACE $TEXT$ .SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44 .SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY .IMPORT $global$,DATA .IMPORT $$dyncall,MILLICODE .SPACE $TEXT$ .NSUBSPA $CODE$ .align 4 .EXPORT bar,ENTRY,PRIV_LEV=3,ARGW0=GR bar: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY bv,n %r0(%r2) .EXIT .PROCEND .SPACE $TEXT$ .NSUBSPA $CODE$ .align 4 .EXPORT baz,ENTRY,PRIV_LEV=3,ARGW0=GR baz: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY bv,n %r0(%r2) .EXIT .PROCEND .SPACE $TEXT$ .NSUBSPA $CODE$ .align 4 .EXPORT main,ENTRY,PRIV_LEV=3,RTNVAL=GR main: .PROC .CALLINFO FRAME=64,CALLS,SAVE_RP .ENTRY stw %r2,-20(%r30) ldi 10,%r26 ldo 64(%r30),%r30 .CALL ARGW0=GR,ARGW1=GR bl foo,%r2 ldi 100,%r25 .CALL ARGW0=GR bl exit,%r2 ldi 0,%r26 nop .EXIT .PROCEND .IMPORT exit,CODE .IMPORT foo,CODE This failure appears to have been introduced after revision 127629 and before or in revision 127680. -- Summary: FAIL: gcc.c-torture/execute/20010119-1.c compilation, - Os Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33154
