Re: gcc cannot recognize 0xe+0x1
Tadahito Kobayashi koval...@gmail.com writes: return 0xe+0x1 ; 0xe+0x1 forms a single preprocessing token (a pp-number), but cannot be converted to a valid token. Add some whitespace around + to break up the preprocessing token. Andreas. -- Andreas Schwab, sch...@linux-m68k.org Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 10:00 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug tree-optimization/39339] New: [4.4 Regression] SRA miscompilation of vte
struct C
{
unsigned int c;
struct D
{
unsigned int columns : 4;
unsigned int fore : 9;
unsigned int back : 9;
unsigned int fragment : 1;
unsigned int standout : 1;
unsigned int underline : 1;
unsigned int strikethrough : 1;
unsigned int reverse : 1;
unsigned int blink : 1;
unsigned int half : 1;
unsigned int bold : 1;
unsigned int invisible : 1;
unsigned int pad : 1;
} attr;
};
struct A
{
struct C *data;
unsigned int len;
};
struct B
{
struct A *cells;
unsigned char soft_wrapped : 1;
};
struct E
{
long row, col;
struct C defaults;
};
__attribute__ ((noinline))
void foo (struct E *screen, unsigned int c, int columns, struct B *row)
{
struct D attr;
long col;
int i;
col = screen-col;
attr = screen-defaults.attr;
attr.columns = columns;
row-cells-data[col].c = c;
row-cells-data[col].attr = attr;
col++;
attr.fragment = 1;
for (i = 1; i columns; i++)
{
row-cells-data[col].c = c;
row-cells-data[col].attr = attr;
col++;
}
}
int
main (void)
{
struct E e = {.row = 5,.col = 0,.defaults =
{6, {-1, -1, -1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0}} };
struct C c[4];
struct A a = { c, 4 };
struct B b = { a, 1 };
struct D d;
__builtin_memset (c, 0, sizeof c);
foo (e, 65, 2, b);
d = e.defaults.attr;
d.columns = 2;
if (__builtin_memcmp (d, c[0].attr, sizeof d))
__builtin_abort ();
d.fragment = 1;
if (__builtin_memcmp (d, c[1].attr, sizeof d))
__builtin_abort ();
return 0;
}
is miscompiled at -O1 and above, works with -fno-tree-sra.
--
Summary: [4.4 Regression] SRA miscompilation of vte
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39339
[Bug tree-optimization/39339] [4.4 Regression] SRA miscompilation of vte
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39339
[Bug rtl-optimization/39338] reduction of in-loop 64-bit multiply to repeated add wrong when loop var wraps neg
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-02 10:03 ---
int i = 0;
for (i = 1; i; ++i) {
invokes undefined behavior (signed overflow is undefined in ISO C).
Use -fwrapv or unsigned arithmetic.
--
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=39338
[Bug target/37520] NO_DOLLAR_IN_LABEL should be defined on x86 targets
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P3 Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-02 10:10 ---
Confirmed.
typedef unsigned char byte;
typedef struct gx_device_s gx_device;
typedef struct gs_devn_params_s gs_devn_params;
typedef struct gs_devn_params_s {
struct compressed_color_list_s * compressed_color_list;
} gs_devn_params_t;
int devn_unpack_row(gx_device * dev, int num_comp,
gs_devn_params * pdevn_params, int width, byte * in,
byte * out)
{
int i, comp_num, pixel_num;
if (pdevn_params-compressed_color_list == ((void *)0))
{
for (pixel_num = 0; pixel_num width; pixel_num++)
for (i = 0; i num_comp; i++)
*out++ = *in++;
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-03-02 10:10:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug c++/39340] New: unnecessarily strict std::norm implementation
g++ 4.3.1 implements std::norm(x) as std::abs(x) squared for built-in floating point types. I believe this is taking the standard too literally. It says std::norm should return magnitude of x squared in the mathematical sense (i.e. a floating-point approximation thereof), which is not necessarily equivalent to the result of std::abs(x) squared. I think the intent of std::norm was clearly to avoid doing a square root if the magnitude is to be squared immediatelly. -- Summary: unnecessarily strict std::norm implementation Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39340
Re: gcc cannot recognize 0xe+0x1
Understood, That's a single token according to the definition of pp-number. It's not a bug. Thanks for kindly teaching. -Kovaltan
[Bug tree-optimization/39339] [4.4 Regression] SRA miscompilation of vte
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-02 10:52 ---
Introduced in r132969.
During esra we have:
D.1656_34 = VIEW_CONVERT_EXPRunsigned int(screen_3(D)-defaults.attr);
D.1657_35 = D.1656_34 23;
attr$B23F9_36 = (unnamed-unsigned:9) D.1657_35;
...
SR.8_37 = attr$B23F9_36 7;
SR.9_50 = (unsigned int) SR.8_37;
SR.10_51 = SR.9_50 23;
SR.11_52 = SR.7_49 | SR.10_51;
D.1634_19-attr ={v} VIEW_CONVERT_EXPRstruct D(SR.11_52);
That 7 is either wrong, or lacks corresponding 7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39339
[Bug lto/39009] [LTO] ICE: in make_decl_rtl, at varasm.c:1288
--- Comment #2 from rob1weld at aol dot com 2009-03-02 11:00 --- (In reply to comment #1) Subject: Re: New: [LTO] ICE: in make_decl_rtl, at varasm.c:1288 Thanks for the bug reports. At this stage, I'm not sure if it's useful to file a bug report for every test in the GCC testsuite. These failures are highly visible already and there are about 1,200 of them, so having a separate bug report for each of them may be excessive. Diego. I was looking for 'dupes' and this is one of two Bugs I would have filed. Confirmed on i686-pc-linux-gnu (Debian 5.0). having a separate bug report for each of them may be excessive # grep make_decl_rtl,\ at\ varasm.c:1288 gcc.log.txt | wc -l 698 Fix this and we fix ~700 errors, likely resulting in the rest of gcc working better and shortening the mail considerably. In the same file we can sometimes get past that line and stuck on the next: # grep make_decl_rtl,\ at\ varasm.c:1295 gcc.log_20090218-601.txt | wc -l 24 The other errors are (for the most part): # grep output_expr_operand,\ at\ lto-function-out.c:1259 gcc.log | wc -l 39 # grep output_tree_with_context,\ at\ lto-function-out.c:3241 gcc.log | wc -l 20 Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39009
[Bug c/39341] New: Feature request: function attribute to save alla used registers
It would be useful to interface C functions with code written in raw assembly to have a function attribute to make a function save and restore every used registers, even flags register if possible. This should not cause big problems because such special functions will still _respect_ the ABI, but would not _expect_ the code around to be so fair. -- Summary: Feature request: function attribute to save alla used registers Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a dot pignotti at sssup dot it GCC host triplet: platform indipendent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug c/39341] Feature request: function attribute to save all used registers
--- Comment #1 from falk at debian dot org 2009-03-02 11:43 --- Why not just use -fcall-saved-reg for the relevant registers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug middle-end/39318] [4.4 Regression] internal compiler error: verify_stmts failed
--- Comment #11 from irar at gcc dot gnu dot org 2009-03-02 11:52 --- Subject: Bug 39318 Author: irar Date: Mon Mar 2 11:52:15 2009 New Revision: 144541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144541 Log: 2009-03-02 Richard Guenther rguent...@suse.de Ira Rosen i...@il.ibm.com PR tree-optimization/39318 * tree-vect-transform.c (vectorizable_call): Transfer the EH region information to the vectorized statement. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr39318.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug c/39341] Feature request: function attribute to save all used registers
--- Comment #2 from a dot pignotti at sssup dot it 2009-03-02 11:54 --- Using -fcall-saved-reg for every reg is a very heavy syntax, and would not work on flags register. I think that a per function attribute would be better. It seems that this feature is actually supported for a couple of architectures (for example blackfin) with the attribute 'saveall' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug tree-optimization/39339] [4.4 Regression] SRA miscompilation of vte
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 12:13 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-02 12:13:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39339
[Bug fortran/39342] New: fails on redefinition of variables
We have a rather large suite of fortran (mostly f90 - some f77) code that we would like to port to gnu fortan. It is today compiled on Sun f90 (derived from Cray CF90). We do have some issues... This might not be defined as a gfortran error - but we do not know (how to find out) Our current compiler allows redefinition of variables. gfortran seems not to. Is there a switch in gfortran that may be used? heres the details example: gfortran -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /t3-0/shared/gnu/gcc-4.3.3/configure --prefix=/t3-0/shared/gnu/gcc-trunk --srcdir=/t3-0/shared/gnu/gcc-4.3.3 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-pkgversion=432 Thread model: posix gcc version 4.3.3 (432) program: SUBROUTINE SLSYNOFX(TSN,UFD,STATUS) INCLUDE 'rvp.mnc' INTEGER :: SL_I4NOVALUEX ! -- DO something RETURN END includefile: cat rvp.mnc ! includefile PARAMETER (SL_I4NOVALUE = Z'8000') INTEGER :: SL_I4NOVALUEX INTEGER :: SL2_I4NOVALUE INTEGER :: SL_I4NOVALUEX running: $gfortran -g -ffree-form -fno-range-check -c rv1.f90 -o rv1.o rvp.mnc:7.30: Included at rv1.f90:2: INTEGER :: SL_I4NOVALUEX 1 Error: Symbol 'sl_i4novaluex' at (1) already has basic type of INTEGER rv1.f90:3.31: INTEGER :: SL_I4NOVALUEX 1 Error: Symbol 'sl_i4novaluex' at (1) already has basic type of INTEGER $ -- Summary: fails on redefinition of variables Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rvatne at gmail dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
[Bug tree-optimization/39343] New: [4.4 Regression] Wrong result for __builtin_object_size (x, 1)
extern inline __attribute__ ((__always_inline__)) int
foo (char *dest)
{
return __builtin_object_size (dest, 1);
}
struct S
{
union
{
struct { int a, b; char c, d; } f;
struct { struct { int a, b; char c, d[255]; } e; } g;
} u;
};
int
main (void)
{
struct S s;
return foo (s.u.g.e.d) 255;
}
fails since:
2008-08-13 Richard Guenther rguent...@suse.de
* tree.h (maybe_fold_offset_to_address): Declare.
* tree-ssa-ccp.c (surely_varying_stmt_p): Fix typo in last commit.
(ccp_fold): Handle pointer conversions the same as fold_stmt.
Likewise for POINTER_PLUS_EXPR.
(maybe_fold_offset_to_reference): Enable disabled code.
(maybe_fold_offset_to_address): New function.
(fold_stmt_r): Use it.
(fold_gimple_assign): Likewise.
* gimplify.c (gimplify_conversion): Use maybe_fold_offset_to_address.
(gimplify_expr): Likewise.
During gimplification foo ((char *) s.u.g.e.d) is changed into:
foo (s.u.f.d), where the former has __builtin_object_size (x, 1) 255, while
the latter just 1.
--
Summary: [4.4 Regression] Wrong result for __builtin_object_size
(x, 1)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39343
[Bug tree-optimization/39343] [4.4 Regression] Wrong result for __builtin_object_size (x, 1)
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-02 12:38 --- This causes valid programs to abort with -D_FORTIFY_SOURCE=2, when strcpy etc. is used to initialize that field. For memcpy etc. it makes no difference, those use __builtin_object_size (x, 0) always. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39343
[Bug fortran/39342] fails on redefinition of variables
--- Comment #1 from kargl at gcc dot gnu dot org 2009-03-02 12:41 --- (In reply to comment #0) We have a rather large suite of fortran (mostly f90 - some f77) code that we would like to port to gnu fortan. It is today compiled on Sun f90 (derived from Cray CF90). We do have some issues... This might not be defined as a gfortran error - but we do not know (how to find out) Our current compiler allows redefinition of variables. gfortran seems not to. Is there a switch in gfortran that may be used? No. The code is invlaid Fortran. The best option is to fix your code. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
[Bug fortran/39342] fails on redefinition of variables
--- Comment #2 from rvatne at gmail dot com 2009-03-02 12:59 --- (In reply to comment #1) (In reply to comment #0) We have a rather large suite of fortran (mostly f90 - some f77) code that we would like to port to gnu fortan. It is today compiled on Sun f90 (derived from Cray CF90). We do have some issues... This might not be defined as a gfortran error - but we do not know (how to find out) Our current compiler allows redefinition of variables. gfortran seems not to. Is there a switch in gfortran that may be used? No. The code is invlaid Fortran. The best option is to fix your code. Is there a (preferred) forum that may be used for this kind of questions, rather than reporting them as gfortran errors?? Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
[Bug fortran/39344] New: fails on redefinition of variables
We have a rather large suite of fortran (mostly f90 - some f77) code that we would like to port to gnu fortan. It is today compiled on Sun f90 (derived from Cray CF90). We do have some issues... This might not be defined as a gfortran error - but we do not know (how to find out) Our current compiler allows redefinition of variables. gfortran seems not to. Is there a switch in gfortran that may be used? heres the details example: gfortran -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /t3-0/shared/gnu/gcc-4.3.3/configure --prefix=/t3-0/shared/gnu/gcc-trunk --srcdir=/t3-0/shared/gnu/gcc-4.3.3 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-pkgversion=432 Thread model: posix gcc version 4.3.3 (432) program: SUBROUTINE SLSYNOFX(TSN,UFD,STATUS) INCLUDE 'rvp.mnc' INTEGER :: SL_I4NOVALUEX ! -- DO something RETURN END includefile: cat rvp.mnc ! includefile PARAMETER (SL_I4NOVALUE = Z'8000') INTEGER :: SL_I4NOVALUEX INTEGER :: SL2_I4NOVALUE INTEGER :: SL_I4NOVALUEX running: $gfortran -g -ffree-form -fno-range-check -c rv1.f90 -o rv1.o rvp.mnc:7.30: Included at rv1.f90:2: INTEGER :: SL_I4NOVALUEX 1 Error: Symbol 'sl_i4novaluex' at (1) already has basic type of INTEGER rv1.f90:3.31: INTEGER :: SL_I4NOVALUEX 1 Error: Symbol 'sl_i4novaluex' at (1) already has basic type of INTEGER $ -- Summary: fails on redefinition of variables Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rvatne at gmail dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39344
[Bug fortran/39342] fails on redefinition of variables
--- Comment #3 from domob at gcc dot gnu dot org 2009-03-02 13:13 --- *** Bug 39344 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
[Bug fortran/39344] fails on redefinition of variables
--- Comment #1 from domob at gcc dot gnu dot org 2009-03-02 13:13 --- *** This bug has been marked as a duplicate of 39342 *** -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39344
[Bug middle-end/39318] [4.4 Regression] internal compiler error: verify_stmts failed
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-03-02 13:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug middle-end/39341] Feature request: function attribute to save all used registers
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-02 13:39 --- First the target needs support for saving those registers. Does it make sense to mark the TOC register as being saved? How about the thread local storage register being saved? Why not used use ABI correctly? Because the raw assembly is just violating the ABI. There is a reason why ABIs exist in the first place :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 13:52 --- Does -fno-strict-aliasing help ? Does -fno-strict-overflow help? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug tree-optimization/39345] New: [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
Building SurfaceMeshGenerator.cpp of FreeFEM3d ICEs with -O and -O2. -- Summary: [4.4 Regression] ICE in copy_tree_body_r, at tree- inline.c:1020 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-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=39345
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-02 14:48 --- Created an attachment (id=17383) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17383action=view) testcase Preprocessed source (x86_64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 14:50 --- Doesn't ICE with -O -g. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug tree-optimization/39343] [4.4 Regression] Wrong result for __builtin_object_size (x, 1)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-02 15:24 --- Testing a patch. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-02 15:24:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39343
[Bug c++/25185] deep typedef substitution in error message
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-02 16:20 --- Created an attachment (id=17384) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17384action=view) patch to disable canonicalization of template type args type canonicalization is the problem here, not a solution; Dave wants to see the typedef name, not the canonical name. Does this patch provide the desired behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #5 from dave at boost-consulting dot com 2009-03-02 16:39 --- Why do you think I want to see the typedef name when I've explicitly asked for the opposite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-03-02 17:00 --- And for trunk we have combiner : 24.76 (15%) usr 0.80 (23%) sys 25.76 (16%) wall 448053 kB (82%) ggc integrated RA : 68.41 (43%) usr 1.06 (31%) sys 70.23 (42%) wall 3197 kB ( 1%) ggc as the worst offenders at -O1. I notice that with --enable-checking GC params the top memory usage is way lower than without, so something odd happens here as well (maybe a ggc_free wrapped inside ENABLE_CHECKING?). Most memory is used by combine and IRA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c++/25185] deep typedef substitution in error message
--- Comment #6 from jason at gcc dot gnu dot org 2009-03-02 17:01 --- Poor reading comprehension? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug target/39346] New: no mxp target port
The official FSF gcc doesn't have a target port to ARC's MXP architecture. -- Summary: no mxp target port Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39346
[Bug other/39347] New: Vector mode class for CCmode is missing
There is no mode class to describe a SIMD condition code register. -- Summary: Vector mode class for CCmode is missing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 OtherBugsDependingO 39346 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
[Bug other/39347] Vector mode class for CCmode is missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:15 --- Is there a reason behind why you want this? SIMD CC modes seems a bit weird . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug other/39348] New: Vector mode class for MODE_PARTIAL_INT is missing
There is no mode class to describe a SIMD partial integer register. -- Summary: Vector mode class for MODE_PARTIAL_INT is missing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 OtherBugsDependingO 39346 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39348
[Bug other/39348] Vector mode class for MODE_PARTIAL_INT is missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:23 --- Vector modes of partial modes does not make sense since partial modes can only be used for pointers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39348
[Bug testsuite/39325] FAIL: gcc.misc-tests/linkage.c link
--- Comment #2 from janis at gcc dot gnu dot org 2009-03-02 17:28 --- Please submit the patch to gcc-patc...@gcc.gnu.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39325
[Bug rtl-optimization/39349] New: cse_insn has out-of-bounds array access
The loop in cse_insn below the comment: /* See if we have a CONST_INT that is already in a wider mode. */ fails to terminate when VOIDmode is reached. -- Summary: cse_insn has out-of-bounds array access Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 OtherBugsDependingO 39346 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39349
[Bug rtl-optimization/39349] cse_insn has out-of-bounds array access
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:39 --- I think this is by defined, you need to include one mode bigger than the register size. This is done for spu the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39349
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-02
17:42 ---
This reduction gives a different (but probably related) ICE:
void crash_me(int num1, int num2, char * in, char * out)
{
int i, j;
for (j = 0; j num1; j++)
for (i = 0; i num2; i++)
*out++ = *in++;
}
$gcc -O1 -floop-interchange -c crash_me.c
crash_me.c: In function 'crash_me':
crash_me.c:7: error: unrecognizable insn:
(insn 24 22 25 6 test.c:5 (set (reg:DI 70)
(reg:SI 62 [ D.1626 ])) -1 (nil))
crash_me.c:7: internal compiler error: in extract_insn, at recog.c:2038
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug rtl-optimization/39350] New: MOVE_BY_PIECES_P is used by rtl optimizers
MOVE_BY_PIECES_P is used by rtl optimizers to determine if a chunk of memory is being moved by pieces. This is wrong when MOVE_BY_PIECES_P returns false in order to allow a movmem expander emit an efficient move sequence. There should be a separate optional target macro to tell if a move will be done in piece, be that via a movmem or via move_by_pieces. can_move_by_pieces should have an extra argument to specify what is actually meant. expand_constructor should use can_move_by_pieces instead of CAN_MOVE_BY_PIECES. -- Summary: MOVE_BY_PIECES_P is used by rtl optimizers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39350
[Bug rtl-optimization/39351] New: compute_init_costs uses unemitted insns
rtl-factoring.c:compute_init_costs calls compute_rtx_cost with instructions that have dangling PREV_INSN and NEXT_INSN pointers. That can lead to crashes when rtx costs depend on context. -- Summary: compute_init_costs uses unemitted insns Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 OtherBugsDependingO 39303 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39351
[Bug rtl-optimization/39351] compute_init_costs uses unemitted insns
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 18:08 --- rtl-factoring.c is so broken that it should be removed ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39351
[Bug rtl-optimization/39351] compute_init_costs uses unemitted insns
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 18:09 --- *** This bug has been marked as a duplicate of 36240 *** -- 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=39351
[Bug rtl-optimization/36240] PIC and -frtl-abstract-sequences
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 18:09 --- *** Bug 39351 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36240
[Bug other/39347] Vector mode class for CCmode is missing
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:16 --- (In reply to comment #1) Is there a reason behind why you want this? SIMD CC modes seems a bit weird The MXP architecture has a SIMD CC register that is pretty close to CC0. I.e. some moves and adds can be done witout affecting this register, but some simply can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
[Bug other/39347] Vector mode class for CCmode is missing
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-02 18:19 --- I still don't understand what you mean by that. Do you mean the registers are vector based and the instructions effect the conditional register and that conditional register has slots (elements) that correspond to the vector slots (elements)? Still having a vector mode of CCmode seems weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
[Bug c++/25185] deep typedef substitution in error message
--- Comment #7 from jason at gcc dot gnu dot org 2009-03-02 18:24 --- Actually this issue has nothing to do with typedefs: rather, for template instantiations GCC prints out the template signature and then the template arguments, rather than the signature of the instantiation. What you're seeing is just the signature of the boost::sequence::detail::range_maker...::operator() template. This change happened in 1999: 1999-09-28 Gabriel Dos Reis g...@codesourcery.com Implement function template instantiation pretty printing. so, before GCC 3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #8 from jason at gcc dot gnu dot org 2009-03-02 18:25 --- Created an attachment (id=17385) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17385action=view) patch to print the instantiated signature as well as template/args Is this more what you're looking for? -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug other/39348] Vector mode class for MODE_PARTIAL_INT is missing
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:26 --- (In reply to comment #1) Vector modes of partial modes does not make sense since partial modes can only be used for pointers. No, they can also be used to describe integer registers with unusual width, or the carry flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39348
[Bug rtl-optimization/39349] cse_insn has out-of-bounds array access
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:29 --- (In reply to comment #1) I think this is by defined, you need to include one mode bigger than the register size. This is done for spu the same way. Where does it say that a port for a target with 128 bit registers and 8*16 bit ALU width has to support 256 bit integers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39349
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 18:33 --- This is introduced by revision 144529: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00031.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-02 18:42 --- I'm seeing it on an ACATS test as well (with local compiler modifications). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-02 18:42:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
Re: [Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
Hi,
The only thing that graphite modifies is from canonicalize_loop_ivs:
here is the diff between 1 that is the debug_loops (3) before
graphite and 2 that is after graphite.
--- 1 2009-03-02 12:20:03.0 -0600
+++ 2 2009-03-02 12:20:18.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
bb 4:
+D.1655_27 = (unsigned int) width_12(D);
+D.1656_25 = D.1655_27 + 4294967295;
goto bb 10;
}
@@ -90,6 +92,8 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
bb 11:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
goto bb 6;
}
@@ -98,16 +102,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
bb 5:
+ivtmp.25_2 = ivtmp.25_4 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
bb 6:
-# in_47 = PHI in_17(5), in_21(11)
-# out_48 = PHI out_16(5), out_32(11)
-# i_49 = PHI i_18(5), 0(11)
# SMT.10_50 = PHI SMT.10_30(5), SMT.10_34(11)
# SMT.11_52 = PHI SMT.11_31(5), SMT.11_35(11)
+# ivtmp.25_4 = PHI ivtmp.25_2(5), 0(11)
+in_47 = in_21 + ivtmp.25_4;
+out_48 = out_32 + ivtmp.25_4;
+i_49 = (int) ivtmp.25_4;
# VUSE SMT.10_50, SMT.11_52 { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF SMT.10_50
@@ -116,7 +122,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) i_18)
+if (ivtmp.25_4 D.1653_6)
goto bb 5;
else
goto bb 7;
The fail is in RTL expand in copy_to_mode_reg:
gcc_assert (GET_MODE (x) == mode || GET_MODE (x) == VOIDmode);
(gdb) p x-mode
$16 = SImode
(gdb) p mode
$17 = DImode
It looks like a type problem for the condition to be expanded:
(gdb) p exp
$18 = (tree) 0x7fa9967d2e00
(gdb) pgs
ivtmp.25 D.1653;
So after figuring out that canonicalize_loop_ivs does compute the
largest precision for all the phi nodes of the loop, such that the new
induction variable can represent all the values of the old IVs, i.e:
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
phi = gsi_stmt (psi);
res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res)) precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1);
it does not fold_convert the number of iterations to this new type,
and thus we end up building a condition with two different precision
types: 32 for niter and 64 for the new IV.
Attached is a fix for this problem, and the diff between 1 before and
5 after graphite looks like this:
--- 1 2009-03-02 12:20:03.0 -0600
+++ 5 2009-03-02 12:54:27.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
bb 4:
+D.1656_25 = (unsigned int) width_12(D);
+D.1657_5 = D.1656_25 + 4294967295;
goto bb 10;
}
@@ -90,6 +92,9 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
bb 11:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
+ D.1654_4 = (long unsigned int) D.1653_6;
goto bb 6;
}
@@ -98,16 +103,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
bb 5:
+ivtmp.25_27 = ivtmp.25_2 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
bb 6:
-# in_47 = PHI in_17(5), in_21(11)
-# out_48 = PHI out_16(5), out_32(11)
-# i_49 = PHI i_18(5), 0(11)
# SMT.10_50 = PHI SMT.10_30(5), SMT.10_34(11)
# SMT.11_52 = PHI SMT.11_31(5), SMT.11_35(11)
+# ivtmp.25_2 = PHI ivtmp.25_27(5), 0(11)
+in_47 = in_21 + ivtmp.25_2;
+out_48 = out_32 + ivtmp.25_2;
+i_49 = (int) ivtmp.25_2;
# VUSE SMT.10_50, SMT.11_52 { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF SMT.10_50
@@ -116,7 +123,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) i_18)
+if (ivtmp.25_2 D.1654_4)
goto bb 5;
else
goto bb 7;
Sebastian Pop
--
AMD - GNU Tools
Index: tree-parloops.c
===
--- tree-parloops.c (revision 144544)
+++ tree-parloops.c (working copy)
@@ -1338,6 +1338,7 @@ canonicalize_loop_ivs (struct loop *loop
affine_iv iv;
edge exit = single_dom_exit (loop);
struct reduction_info *red;
+ gimple_seq stmts;
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
@@ -1351,6 +1352,11 @@ canonicalize_loop_ivs (struct loop *loop
type = lang_hooks.types.type_for_size (precision, 1);
+ nit = fold_convert (type, nit);
+ nit = force_gimple_operand (nit, stmts, true, NULL_TREE);
+ if (stmts)
+gsi_insert_seq_on_edge_immediate
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #5 from sebpop at gmail dot com 2009-03-02 18:57 ---
Subject: Re: ICE in GCC 4.4 with -O[123]
-floop-interchange
Hi,
The only thing that graphite modifies is from canonicalize_loop_ivs:
here is the diff between 1 that is the debug_loops (3) before
graphite and 2 that is after graphite.
--- 1 2009-03-02 12:20:03.0 -0600
+++ 2 2009-03-02 12:20:18.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
bb 4:
+D.1655_27 = (unsigned int) width_12(D);
+D.1656_25 = D.1655_27 + 4294967295;
goto bb 10;
}
@@ -90,6 +92,8 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
bb 11:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
goto bb 6;
}
@@ -98,16 +102,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
bb 5:
+ivtmp.25_2 = ivtmp.25_4 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
bb 6:
-# in_47 = PHI in_17(5), in_21(11)
-# out_48 = PHI out_16(5), out_32(11)
-# i_49 = PHI i_18(5), 0(11)
# SMT.10_50 = PHI SMT.10_30(5), SMT.10_34(11)
# SMT.11_52 = PHI SMT.11_31(5), SMT.11_35(11)
+# ivtmp.25_4 = PHI ivtmp.25_2(5), 0(11)
+in_47 = in_21 + ivtmp.25_4;
+out_48 = out_32 + ivtmp.25_4;
+i_49 = (int) ivtmp.25_4;
# VUSE SMT.10_50, SMT.11_52 { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF SMT.10_50
@@ -116,7 +122,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) i_18)
+if (ivtmp.25_4 D.1653_6)
goto bb 5;
else
goto bb 7;
The fail is in RTL expand in copy_to_mode_reg:
gcc_assert (GET_MODE (x) == mode || GET_MODE (x) == VOIDmode);
(gdb) p x-mode
$16 = SImode
(gdb) p mode
$17 = DImode
It looks like a type problem for the condition to be expanded:
(gdb) p exp
$18 = (tree) 0x7fa9967d2e00
(gdb) pgs
ivtmp.25 D.1653;
So after figuring out that canonicalize_loop_ivs does compute the
largest precision for all the phi nodes of the loop, such that the new
induction variable can represent all the values of the old IVs, i.e:
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
phi = gsi_stmt (psi);
res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res)) precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1);
it does not fold_convert the number of iterations to this new type,
and thus we end up building a condition with two different precision
types: 32 for niter and 64 for the new IV.
Attached is a fix for this problem, and the diff between 1 before and
5 after graphite looks like this:
--- 1 2009-03-02 12:20:03.0 -0600
+++ 5 2009-03-02 12:54:27.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
bb 4:
+D.1656_25 = (unsigned int) width_12(D);
+D.1657_5 = D.1656_25 + 4294967295;
goto bb 10;
}
@@ -90,6 +92,9 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
bb 11:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
+ D.1654_4 = (long unsigned int) D.1653_6;
goto bb 6;
}
@@ -98,16 +103,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
bb 5:
+ivtmp.25_27 = ivtmp.25_2 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
bb 6:
-# in_47 = PHI in_17(5), in_21(11)
-# out_48 = PHI out_16(5), out_32(11)
-# i_49 = PHI i_18(5), 0(11)
# SMT.10_50 = PHI SMT.10_30(5), SMT.10_34(11)
# SMT.11_52 = PHI SMT.11_31(5), SMT.11_35(11)
+# ivtmp.25_2 = PHI ivtmp.25_27(5), 0(11)
+in_47 = in_21 + ivtmp.25_2;
+out_48 = out_32 + ivtmp.25_2;
+i_49 = (int) ivtmp.25_2;
# VUSE SMT.10_50, SMT.11_52 { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF SMT.10_50
@@ -116,7 +123,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) i_18)
+if (ivtmp.25_2 D.1654_4)
goto bb 5;
else
goto bb 7;
Sebastian Pop
--
AMD - GNU Tools
--- Comment #6 from sebpop at gmail dot com 2009-03-02 18:57 ---
Created an attachment (id=17386)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17386action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug other/39347] Vector mode class for CCmode is missing
--- Comment #4 from amylaar at gcc dot gnu dot org 2009-03-02 18:59 --- (In reply to comment #3) I still don't understand what you mean by that. Do you mean the registers are vector based and the instructions effect the conditional register and that conditional register has slots (elements) that correspond to the vector slots (elements)? Exactly. The conditiona register is known as V8CCImode for ordinary integer instructions, V8CCZNmode if only N/Z flags matter, and V8CCZmode when only the Z falg is relevant. You can copy it from/to a general purpose vector register, in which case it looks like a V8PHImode register with 6 valid bits per element. There are also use cases where it acts as having 32 bit partial elements. Still having a vector mode of CCmode seems weird. Actually, it makes more sense than a scalar CCmode register. The limited clock frequency is compensated for by higher throughput per cycle. Van Neumann would have said that having a processor with 4 or 5 different types of physical memory (L1 Dcache, L1 Icache, L2 cache, maybe L3 cache, main memory) seems weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
[Bug rtl-optimization/39349] cse_insn has out-of-bounds array access
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 19:00 --- FWIW, I defined OImode (512bit) for AVX. It isn't strictly needed by x86 backend. But I had to define it. Otherwise, middle-end isn't happy. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39349
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #7 from spop at gcc dot gnu dot org 2009-03-02 19:05 ---
Subject: Re: ICE in GCC 4.4 with -O[123]
-floop-interchange
On Mon, Mar 2, 2009 at 11:42, il dot basso dot buffo at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-02
17:42 ---
This reduction gives a different (but probably related) ICE:
void crash_me(int num1, int num2, char * in, char * out)
{
int i, j;
for (j = 0; j num1; j++)
for (i = 0; i num2; i++)
*out++ = *in++;
}
$gcc -O1 -floop-interchange -c crash_me.c
crash_me.c: In function 'crash_me':
crash_me.c:7: error: unrecognizable insn:
(insn 24 22 25 6 test.c:5 (set (reg:DI 70)
(reg:SI 62 [ D.1626 ])) -1 (nil))
crash_me.c:7: internal compiler error: in extract_insn, at recog.c:2038
This is fixed as well by the patch that I sent out. I'm bootstrapping
and testing it.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug middle-end/39352] New: gfortran.dg/vect/pr39318.f90 doesn't work on ia64
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/../../ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/vect/pr39318.f90 -O -c -fopenmp -fexceptions -O2 -ftree-vectorize -S -o pr39318.s /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/vect/pr39318.f90: In function adw_trajsp_.omp_fn.0: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/vect/pr39318.f90:10: 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. [...@gnu-14 gfortran]$ -- Summary: gfortran.dg/vect/pr39318.f90 doesn't work on ia64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
[Bug testsuite/39353] New: Linker warning causing tests to fail (960218 and 20030913)
The global variable glob clashes with the compatibility NetBSD libc function with the same name. The linker emits a warning that causes the test case to fail. The included patch renames glob to Glob in both tests -- Summary: Linker warning causing tests to fail (960218 and 20030913) Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
[Bug testsuite/39353] Linker warning causing tests to fail (960218 and 20030913)
--- Comment #1 from aran at 100acres dot us 2009-03-02 19:42 --- Created an attachment (id=17387) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17387action=view) Rename glob to Glob. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #7 from aran at 100acres dot us 2009-03-02 20:09 --- Created an attachment (id=17388) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17388action=view) Gcc 4.3.3 Ada runtime patch for NetBSD 5.0 This patch implements the Ada runtime for NetBSD 5.99. It requires the NetBSD patch that makes GCC compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-02 20:09 --- Created an attachment (id=17389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17389action=view) New fix that adds function cv-qual handling to is_function, and fixes compiler to allow that Here's a fix along those lines. -- jason at gcc dot gnu dot org changed: What|Removed |Added Attachment #17367|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #8 from aran at 100acres dot us 2009-03-02 20:13 --- Created an attachment (id=17390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17390action=view) Gcc 4.3.3 build patch This patch fixes the header problems that prevent GCC 4.3.3 from compiling on NetBSD. This also remove the GCC's copies of sys/types.h and cdecl.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug fortran/39342] fails on redefinition of variables
--- Comment #4 from kargl at gcc dot gnu dot org 2009-03-02 20:23 --- Is there a (preferred) forum that may be used for this kind of questions, rather than reporting them as gfortran errors?? Regards comp.lang.fortarn newsgroup is a great place to ask questions. Several members and former members of the Fortran Standards Committee answer questions. You can also post to fort...@gcc.gnu.org. This mailing list is used fro discussion of gfortran development. The active posters typically do not mind a few general questions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
[Bug c++/25185] deep typedef substitution in error message
--- Comment #9 from dave at boost-consulting dot com 2009-03-02 20:24 --- Hi Jason, Please assume I know what I'm asking for and stop turning it into a different problem. Go back and look at the original report more closely, particularly the part that discusses boost::result_ofCalcSize ()()::type. And lastly, I don't know GCC internals, so I'm unable to interpret the result of your proposed fix (of a problem I'm not having). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #10 from jason at redhat dot com 2009-03-02 20:35 --- Subject: Re: deep typedef substitution in error message dave at boost-consulting dot com wrote: Please assume I know what I'm asking for and stop turning it into a different problem. I know what you're asking for. I was explaining what GCC is doing that is giving you something other than what you want. It isn't that GCC is preserving typedefs, it's that GCC is dumping the signature of the template rather than the instantiation. Go back and look at the original report more closely, particularly the part that discusses boost::result_ofCalcSize ()()::type. That comes from here: typedef range Elements , Begin , End , typename result_ofCalcSize()::type type; template class L, class B, class E, class C type operator()( L const m , B const b , E const e , C const s ) const That's what GCC is printing out. And then it gives the arguments for all the template parameters. To resolve the typename above GCC would have to print the instantiated signature, which it currently doesn't do. And lastly, I don't know GCC internals, so I'm unable to interpret the result of your proposed fix (of a problem I'm not having). I figured you could apply the patch, rebuild GCC and see if the output was more to your liking. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #11 from jason at redhat dot com 2009-03-02 20:43 --- Subject: Re: deep typedef substitution in error message jason at redhat dot com wrote: I figured you could apply the patch, rebuild GCC and see if the output was more to your liking. But I suppose it's easier to just show you the output: ../../../../boost/sequence/make_range.hpp:60: instantiated from boost::sequence::range_::rangeboost::sequence::identity_property_map, char*, char*, mpl_::integral_cunsigned int, 5u boost::sequence::detail::range_makerboost::sequence::identity_property_map, char*, char*, boost::sequence::detail::size_differenceboost::arraychar, 11u, boost::arraychar, 6u ::operator()(const boost::sequence::identity_property_map, char* const, char* const, const boost::sequence::detail::size_differenceboost::arraychar, 11u, const boost::arraychar, 6u ) const [instantiated from boost::sequence::range_::rangeElements, Begin, End, typename boost::result_ofCalcSize ()()::type boost::sequence::detail::range_makerElements, Begin, End, CalcSize::operator()(const L, const B, const E, const C) const with L = boost::sequence::identity_property_map, B = char*, E = char*, C = boost::sequence::detail::size_differenceboost::arraychar, 11u, const boost::arraychar, 6u , Elements = boost::sequence::identity_property_map, Begin = char*, End = char*, CalcSize = boost::sequence::detail::size_differenceboost::arraychar, 11u, boost::arraychar, 6u ] compared to ../../../../boost/sequence/make_range.hpp:60: instantiated from boost::sequence::range_::rangeElements, Begin, End, typename boost::result_ofCalcSize ()()::type boost::sequence::detail::range_makerElements, Begin, End, CalcSize::operator()(const L, const B, const E, const C) const [with L = boost::sequence::identity_property_map, B = char*, E = char*, C = boost::sequence::detail::size_differenceboost::arraychar, 11u, const boost::arraychar, 6u , Elements = boost::sequence::identity_property_map, Begin = char*, End = char*, CalcSize = boost::sequence::detail::size_differenceboost::arraychar, 11u, boost::arraychar, 6u ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug middle-end/39352] gfortran.dg/vect/pr39318.f90 doesn't work on ia64
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-02 20:50 --- -fexceptions with Fortran looks odd. Does Fortran support exceptions? To support exceptions, C/C++ initializes eh_personality_libfunc. But eh_personality_libfunc isn't initialized for Fortran. What does it mean? Does Fortran support/need LSDA? output_function_exception_table has /* Not all functions need anything. */ if (! crtl-uses_eh_lsda) return; if (eh_personality_libfunc) assemble_external_libcall (eh_personality_libfunc); #ifdef TARGET_UNWIND_INFO /* TODO: Move this into target file. */ fputs (\t.personality\t, asm_out_file); output_addr_const (asm_out_file, eh_personality_libfunc); fputs (\n\t.handlerdata\n, asm_out_file); /* Note that varasm still thinks we're in the function's code section. The .endp directive that will immediately follow will take us back. */ #else switch_to_exception_section (fnname); #endif Since eh_personality_libfunc is NULL for Fortran, we crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
[Bug middle-end/39352] gfortran.dg/vect/pr39318.f90 doesn't work on ia64
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 20:51 --- -fexceptions does not seem weird. Since you can call Fortran from C++ code and want to unwind there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
[Bug fortran/39352] gfortran.dg/vect/pr39318.f90 doesn't work on ia64
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 20:54 --- (In reply to comment #2) -fexceptions does not seem weird. Since you can call Fortran from C++ code and want to unwind there. I don't believe Fortran front-end has properly set up to support exceptions. -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|middle-end |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #45 from pluto at agmk dot net 2009-03-02 21:04 --- bug ping... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #13 from aesok at gcc dot gnu dot org 2009-03-02 21:54 --- *** Bug 38558 has been marked as a duplicate of this bug. *** -- aesok at gcc dot gnu dot org changed: What|Removed |Added CC||jw at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug target/38558] [avr] ICE on function attribute syntax for __vectorN()
--- Comment #1 from aesok at gcc dot gnu dot org 2009-03-02 21:54 --- *** This bug has been marked as a duplicate of 34299 *** -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38558
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #3 from galtgendo at o2 dot pl 2009-03-02 21:56 --- I'll check, but, as summary suggests (indirectly), '-O2 -fno-inline-small-functions' works just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #46 from hjl dot tools at gmail dot com 2009-03-02 21:59 --- (In reply to comment #42) Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) [edit] internal-error-testcase I got gnu-6:pts/4[294] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x gnu-6:pts/4[295] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x -O gnu-6:pts/4[296] ./xgcc -B./ -S /tmp/smsSimClock.ii -std=gnu++0x -O2 with gcc 4.4 revision 144547. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #8 from spop at gcc dot gnu dot org 2009-03-02 22:07 --- Subject: Bug 39335 Author: spop Date: Mon Mar 2 22:07:10 2009 New Revision: 144555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144555 Log: 2009-03-02 Sebastian Pop sebastian@amd.com PR middle-end/39335 * tree-parloops.c (canonicalize_loop_ivs): Call fold_convert when the type precision of the induction variable should be larger than the type precision of nit. (gen_parallel_loop): Update use of canonicalize_loop_ivs. * graphite-clast-to-gimple.c (graphite_loop_normal_form): Same. * tree-flow.h (canonicalize_loop_ivs): Update declaration. * testsuite/gcc.dg/graphite/pr39335_1.c: New. * testsuite/gcc.dg/graphite/pr39335.c: New. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr39335.c branches/graphite/gcc/testsuite/gcc.dg/graphite/pr39335_1.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-clast-to-gimple.c branches/graphite/gcc/tree-flow.h branches/graphite/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #4 from galtgendo at o2 dot pl 2009-03-02 22:20 --- Well, neither helps. As a sidenote: 'gcc -Q -O2 --help=optimizers' fails to list '-fstrict-overflow', -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-02 22:43 --- (In reply to comment #3) I'll check, but, as summary suggests (indirectly), '-O2 -fno-inline-small-functions' works just fine. But that just enables more inlining. The problem is most likely somewhere else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug fortran/39354] New: bad codegen for openmp atomics (Intel64 Fortran logical ops)
It looks like bug #34020 (reported against IPF Fortran) is also happening with Intel64 Fortran logical ops. The lhs operand is not reloaded if the cmpxchg fails. Testcase: SUBROUTINE test(lhs, rhs) LOGICAL lhs, rhs !$omp atomic lhs = lhs .or. rhs END % gfortran -fopenmp test.f -S fxedlin09 % head -47 test.s .file test.f .text .globl test_ .type test_, @function test_: .LFB2: pushq %rbp .LCFI0: movq%rsp, %rbp .LCFI1: pushq %rbx .LCFI2: movq%rdi, -16(%rbp) movq%rsi, -24(%rbp) movq-24(%rbp), %rax movl(%rax), %eax ; load lhs movl%eax, -28(%rbp) movq-16(%rbp), %rax movl(%rax), %eax ; load rhs testl %eax, %eax jne .L2 cmpl$0, -28(%rbp) je .L3 .L2: movl$1, -32(%rbp) jmp .L4 .L3: movl$0, -32(%rbp) .L4: movq-16(%rbp), %rax movl(%rax), %eax movl%eax, -36(%rbp) .L5: movq-16(%rbp), %rax movq%rax, -48(%rbp) movq-48(%rbp), %rcx movl-36(%rbp), %eax movl-32(%rbp), %ebx lock cmpxchgl %ebx, (%rcx) movl%eax, %edx movl-36(%rbp), %eax movl%edx, -36(%rbp) cmpl%eax, %edx jne .L5; need to jump to .LCFI2, not .L5 popq%rbx leave ret gfortran version info: version 4.3.3 20090119 (prerelease) [gcc-4_3-branch revision 143496]. -- Summary: bad codegen for openmp atomics (Intel64 Fortran logical ops) Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brian dot e dot bliss at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39354
[Bug fortran/34020] Bogus codegen for openmp atomics w/ indirects operands on IPF
--- Comment #6 from brian dot e dot bliss at intel dot com 2009-03-02 22:47 --- See 39354. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34020
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-02 23:47 ---
can_be_nonlocal calls remap_type to return the remapped type. But
it isn't stored anywhere. Is that intentional? I don't know if
this patch makes any senses. It fixed ICE.
Index: tree-inline.c
===
--- tree-inline.c (revision 144529)
+++ tree-inline.c (working copy)
@@ -426,6 +426,23 @@ remap_type (tree type, copy_body_data *i
return tmp;
}
+static tree
+have_remap_type (tree type, copy_body_data *id)
+{
+ tree *node;
+
+ if (type == NULL)
+return type;
+
+ /* See if we have remapped this type. */
+ node = (tree *) pointer_map_contains (id-decl_map, type);
+ if (node)
+return *node;
+ else
+return NULL;
+}
+
+ /* The type only needs remapping if it's variably modified. */
/* Decide if DECL can be put into BLOCK_NONLOCAL_VARs. */
static bool
@@ -447,7 +464,7 @@ can_be_nonlocal (tree decl, copy_body_da
return false;
/* We must use global type. */
- if (TREE_TYPE (decl) != remap_type (TREE_TYPE (decl), id))
+ if (TREE_TYPE (decl) != have_remap_type (TREE_TYPE (decl), id))
return false;
/* Wihtout SSA we can't tell if variable is used. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #6 from galtgendo at o2 dot pl 2009-03-03 00:20 --- (In reply to comment #5) But that just enables more inlining. The problem is most likely somewhere else. If so, why does '-O2' fail and '-O2 -fno-inline-small-functions' work ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-03-03 00:21 --- (In reply to comment #6) If so, why does '-O2' fail and '-O2 -fno-inline-small-functions' work ? Because you just disabled some extra inlining. try -O2 -fno-inline-small-functions -finline-functions and you will see that it still fails. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug debug/39355] New: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
Executing on host: /home/dave/gnu/gcc-4.4/objdir/./gcc/g++ -shared-libgcc -B/hom e/dave/gnu/gcc-4.4/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/ src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/ -B/home/dave/opt/gn u/gcc/gcc-4.4.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-l inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++ -I/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/ gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.4/gcc/ libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/include/backwar d -I/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc -include bits/stdc++.h ./libtestc++.a -lm -o ./13450.exe(timeout = 600)/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc: In function 'std::complex_Tp std::pow(const _Tp, const std::complex_Tp) [with _Tp = double]':/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:37: internal compiler error: Segmentation fault Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups Program received signal SIGSEGV, Segmentation fault. loc_descriptor_from_tree_1 (loc=0x0, want_address=2) at ../../gcc/gcc/dwarf2out.c:10353 10353 switch (TREE_CODE (loc)) (gdb) bt #0 loc_descriptor_from_tree_1 (loc=0x0, want_address=2) at ../../gcc/gcc/dwarf2out.c:10353 #1 0x00291d8c in loc_descriptor_from_tree_1 (loc=0x6082ab00, want_address=2) at ../../gcc/gcc/dwarf2out.c:10438 #2 0x00298c2c in add_location_or_const_value_attribute (die=0x40443c90, decl=0x6082ab00, attr=value optimized out) at ../../gcc/gcc/dwarf2out.c:10789 #3 0x0029d70c in gen_formal_parameter_die (node=0x0, origin=0x40408150, context_die=0x40443c00) at ../../gcc/gcc/dwarf2out.c:13328 #4 0x0029a340 in gen_decl_die (decl=0x0, origin=0x6082ab00, context_die=0x40443c00) at ../../gcc/gcc/dwarf2out.c:15378 #5 0x0029fe84 in decls_for_scope (stmt=0x40448d58, context_die=0x40443c00, depth=3) at ../../gcc/gcc/dwarf2out.c:14986 #6 0x002a1ff8 in gen_lexical_block_die (stmt=0x40448d58, context_die=value optimized out, depth=3) at ../../gcc/gcc/dwarf2out.c:14225 #7 0x002a25d4 in gen_block_die (stmt=0x40448d58, context_die=0x40443cf0, depth=3) at ../../gcc/gcc/dwarf2out.c:14930 #8 0x0029fec4 in decls_for_scope (stmt=0x40448d20, context_die=0x40443cf0, depth=value optimized out) at ../../gcc/gcc/dwarf2out.c:14998 #9 0x002a23d0 in gen_block_die (stmt=0x40448d20, context_die=0x40443cf0, depth=2) at ../../gcc/gcc/dwarf2out.c:14933 #10 0x0029fec4 in decls_for_scope (stmt=0x40448ce8, context_die=0x40443cf0, ---Type return to continue, or q return to quit--- depth=value optimized out) at ../../gcc/gcc/dwarf2out.c:14998 #11 0x002a1ff8 in gen_lexical_block_die (stmt=0x40448ce8, context_die=value optimized out, depth=1) at ../../gcc/gcc/dwarf2out.c:14225 #12 0x002a25d4 in gen_block_die (stmt=0x40448ce8, context_die=0x40443b70, depth=1) at ../../gcc/gcc/dwarf2out.c:14930 #13 0x0029fec4 in decls_for_scope (stmt=0x403416c8, context_die=0x40443b70, depth=value optimized out) at ../../gcc/gcc/dwarf2out.c:14998 #14 0x002a02c0 in gen_subprogram_die (decl=0x4036cd00, context_die=0x22) at ../../gcc/gcc/dwarf2out.c:13838 #15 0x0029a47c in gen_decl_die (decl=0x4036cd00, origin=0x0, context_die=0x602efe80) at ../../gcc/gcc/dwarf2out.c:15292 #16 0x0029a020 in dwarf2out_abstract_function (decl=0x4036cd00) at ../../gcc/gcc/dwarf2out.c:13489 #17 0x001d7f34 in expand_call_inline (bb=0x40447940, stmt=0x403ae370, id=0xfb66c130) at ../../gcc/gcc/tree-inline.c:3448 #18 0x001d919c in optimize_inline_calls (fn=0x4036ef00) at ../../gcc/gcc/tree-inline.c:3477 #19 0x0068a040 in cgraph_early_inlining () at ../../gcc/gcc/ipa-inline.c:1530 #20 0x00413664 in execute_one_pass (pass=0x996528) at ../../gcc/gcc/passes.c:1277 #21 0x004138f8 in execute_pass_list (pass=0x996528) at ../../gcc/gcc/passes.c:1326 ---Type return to continue, or q return to quit--- #22 0x0041390c in execute_pass_list (pass=0x91f5d4) at ../../gcc/gcc/passes.c:1327 #23 0x00413cc0 in execute_ipa_pass_list (pass=0x91f5a0) at ../../gcc/gcc/passes.c:890 #24 0x0068406c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1239 #25 0x000cf248 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3645 #26 0x004cbc40 in toplev_main (argc=value optimized out, argv=value optimized out) at ../../gcc/gcc/toplev.c:981 #27 0x406495a4 in __libc_start_main () from /lib/libc.so.6 #28
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-03 02:09 --- Subject: Re: New: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 Attached preprocessed source. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-03 02:09 --- Created an attachment (id=17391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17391action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #8 from galtgendo at o2 dot pl 2009-03-03 03:23 --- OK, we seem to misunderstand each other. Anyway, as '-Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations' was set for all files during build and there were no warnings, the problem is probably non-trivial (though seeing just how much inlining is used is this file, I wouldn't be surprised, if it's 50/50 on gcc/freeciv). When I added '-Wextra', most of the new warnings were of either 'unused argument' or 'signed/unsinged comparison' type - in this file, there were no other. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #9 from galtgendo at o2 dot pl 2009-03-03 03:43 --- BTW, this is the workaround, that upstream created: http://svn.gna.org/viewcvs/freeciv/trunk/common/aicore/cm.c?rev=15556view=diffr1=15556r2=1p1=trunk/common/aicore/cm.cp2=/trunk/common/aicore/cm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #9 from spop at gcc dot gnu dot org 2009-03-03 03:47 --- Subject: Bug 39335 Author: spop Date: Tue Mar 3 03:47:22 2009 New Revision: 144564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144564 Log: 2009-03-02 Sebastian Pop sebastian@amd.com PR middle-end/39335 * tree-parloops.c (canonicalize_loop_ivs): Call fold_convert when the type precision of the induction variable should be larger than the type precision of nit. (gen_parallel_loop): Update use of canonicalize_loop_ivs. * graphite.c (graphite_loop_normal_form): Same. * tree-flow.h (canonicalize_loop_ivs): Update declaration. * testsuite/gcc.dg/graphite/pr39335_1.c: New. * testsuite/gcc.dg/graphite/pr39335.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr39335.c trunk/gcc/testsuite/gcc.dg/graphite/pr39335_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
--- Comment #10 from spop at gcc dot gnu dot org 2009-03-03 03:48 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-03-03 03:51
---
for (i = 0, j = 0; i lattice-size || forced_loop; i++) {
i is signed and lattice-size is unsigned so there might be some wrapping.
plus if (lattice-size 0) {
will be changed into lattice-size != 0 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c
--- Comment #9 from irar at gcc dot gnu dot org 2009-03-03 07:42 --- Subject: Bug 39248 Author: irar Date: Tue Mar 3 07:42:26 2009 New Revision: 144569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144569 Log: PR tree-optimization/39248 * gcc.dg/vect/vect-complex-1.c: Add attribute aligned to the arrays. * gcc.dg/vect/vect-iv-6.c: Don't expect to fail to vectorize on targets without vector misalignment support. * lib/target-supports.exp (check_effective_target_vect_short_mult): Add check_effective_target_arm32. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-complex-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-iv-6.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39248
