[Bug fortran/32600] [ISO Bind C] C_LOC/C_FUNLOC should not be library functions
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-19 06:14 --- Subject: Bug 32600 Author: burnus Date: Thu Jul 19 06:14:19 2007 New Revision: 126744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126744 Log: 2007-07-19 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/32600 * trans-expr.c (gfc_conv_function_call): Inline C_LOC. 2007-07-19 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/32600 * libgfortran/intrinsics/iso_c_binding.c: Remove C_LOC. * libgfortran/intrinsics/iso_c_binding.h: Ditto. * libgfortran/gfortran.map: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/iso_c_binding.c trunk/libgfortran/intrinsics/iso_c_binding.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-19 06:59 --- It's known that -O2 contain -fstrict-aliasing which has bugs since gcc 3.X. Huh? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815
[Bug fortran/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 07:00 --- I think the gimplifier is broken though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug fortran/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 06:35 --- This regression is caused by r126647 | fxcoudert | 2007-07-15 01:59:00 +0200 (So, 15 Jul 2007) | 7 lines PR 32036 * trans-array.c (gfc_conv_array_ref): Only evaluate index once. Without bounds check, the if is already optimized away in the original dump. If one adds something in the if body then w/out -fbounds-check: if (k[(int8) i + -1] == 0) and w/: if (k[NON_LVALUE_EXPR SAVE_EXPR (int8) i + -1] == 0) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-19 06:35:59 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
--- Comment #4 from cnstar9988 at gmail dot com 2007-07-19 07:03 --- When I build gcc-4.2.1(prelease) on HPUX11.11, there is some warning.. why the share library build by GCC4.X on HPUX11.11 can't work.. some symbol required by the shared library could not be found. But these works on by GCC3.4.6 or native hpcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815
[Bug target/32338] [4.3 Regression] Error: .prologue within prologue
--- Comment #6 from jakub at gcc dot gnu dot org 2007-07-19 07:03 --- Created an attachment (id=13938) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13938action=view) gcc43-pr32338-3.patch Testing showed I was wrong with the .body and we need duplicate .body even when there was no second .prologue. This updated patch has been bootstrapped/regtested on ia64-linux. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #13936|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
--- Comment #5 from cnstar9988 at gmail dot com 2007-07-19 07:05 --- (In reply to comment #3) It's known that -O2 contain -fstrict-aliasing which has bugs since gcc 3.X. Huh? from 4.2.1 status report. PR 32182 -fstrict-aliasing ... PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815
[Bug fortran/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-19 07:08 --- (In reply to comment #2) I think the gimplifier is broken though. I take that back, the function is called from the front-end so it is not the gimplifier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.
--- Comment #19 from cnstar9988 at gmail dot com 2007-07-19 07:17 --- I have Modify $(GCC)/Makefile.in LDFLAGS=-lpthread BOOT_LDFLAGS=-lpthread So build ok. -- cnstar9988 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-19 07:23 --- Actually it turns out this is a middle-end issue with fold. I am fixing this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-19 07:28 ---
And here is the patch which fixes the issue:
Index: fold-const.c
===
--- fold-const.c(revision 126739)
+++ fold-const.c(working copy)
@@ -3278,6 +3278,9 @@
{
tree t = fold_convert (type, result);
+ if (IS_EMPTY_STMT (t) TREE_SIDE_EFFECTS (omitted))
+return build1 (NOP_EXPR, void_type_node, fold_ignored_result (omitted));
+
if (TREE_SIDE_EFFECTS (omitted))
return build2 (COMPOUND_EXPR, type, fold_ignored_result (omitted), t);
@@ -3291,6 +3294,9 @@
{
tree t = fold_convert (type, result);
+ if (IS_EMPTY_STMT (t) TREE_SIDE_EFFECTS (omitted))
+return build1 (NOP_EXPR, void_type_node, fold_ignored_result (omitted));
+
if (TREE_SIDE_EFFECTS (omitted))
return build2 (COMPOUND_EXPR, type, fold_ignored_result (omitted), t);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-19 07:30 --- Note also save_expr can be made better so we don't need to use a SAVE_EXPR for local variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug fortran/32804] ISO C Binding: C_LOC argument checking needs improvement
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 08:30 --- For the accept-invalid part (c_loc of an assumed-shape array). The standard says: X shall either (1) have interoperable type and type parameters and be (a) a variable that has the TARGET attribute and is interoperable, This variable has the TARGET attribute, but is not interoperable: An array Fortran variable is interoperable if its type and type parameters are interoperable and it is of explicit shape or assumed size. Thus this error by NAG f95 is ok; however, as it is accepted by ifort, g95 and (currently) gfortran. As I completely fail to see any valid use of it and see several cases where it seems to work but one uses in reality the wrong array element, I favour to not allowing it even for -std=gnu. But if one finds a valid use, I'm also fine with an error only for -std=f2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32804
[Bug fortran/32816] New: Compile-time check for No data-edit descriptor for effective item
Test case:
-
program test
implicit none
integer :: n
n = 1
write(*,'(''n'')') n
end program test
-
gfortran gives no compile-time error/warning, only the run-time error:
Fortran runtime error: Insufficient data descriptors in format after reversion
Expected: compile-time error as NAG f95:
Error: r.f90, line 5: No data-edit descriptor for effective item
--
Summary: Compile-time check for No data-edit descriptor for
effective item
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32816
[Bug fortran/32817] New: inline (pure) accessor functions
I don't know whether this is possible to achieve, but simple PURE functions should sometimes be inlined. Please consider: $ cat inline.f90 MODULE foomod TYPE foo PRIVATE ! change to PUBLIC to run the inlined loop INTEGER :: value END TYPE INTERFACE OPERATOR(==) MODULE PROCEDURE foo_equal END INTERFACE CONTAINS PURE FUNCTION foo_new(value) RESULT (this) INTEGER, INTENT(in) :: value TYPE(foo) :: this this = foo(value) END FUNCTION PURE FUNCTION foo_equal(this, other) TYPE(foo), INTENT(in) :: this, other LOGICAL :: foo_equal foo_equal = (this%value == other%value) END FUNCTION END MODULE USE foomod INTEGER :: i, j TYPE(foo) :: x(5) DO i = 1, SIZE(x) x(i) = foo_new(i) END DO DO i = 1, SIZE(x) DO j = i + 1, SIZE(x) IF (x(i) == x(j)) EXIT! call foo_equal END DO END DO !DO i = 1, SIZE(x) ! DO j = i + 1, SIZE(x) !IF (x(i)%value == x(j)%value) EXIT ! inlined ! END DO !END DO END Using comparison function foo_equal $ gfortran-svn -O3 inline.f90 time ./a.out real0m6.818s user0m6.772s sys 0m0.036s Inlined access: $ gfortran-svn -O3 inline.f90 time ./a.out real0m1.242s user0m1.236s sys 0m0.008s The example above was taken from a real-world application that (currently) spends about 10% of its 3 hour runtime in accessor/comparison functions like the one shown. In general, I'd prefer the OO'ish approach over PUBLIC access to the components. -- Summary: inline (pure) accessor functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug fortran/32817] inline (pure) accessor functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-19 09:00 --- I think this is just the normal inline function problem with gfortran. Where we have two decls for the same function which causes no inlining to happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug fortran/32817] inline (pure) accessor functions
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-19 09:17 --- Andrew, you mentioned the two-decl per function elsewhere as well. Where can one learn more about this? why do we have two decls at all? where do they come from, where do they go? How are they dealt with? I'm sort of lost there ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug c/32818] New: i486 assembler bug (GLIBC 2.6) or feature?
Everything works with GCC 4.2.1 but this is the real pain:
Trying to build Glibc from CVS redhat repo got this message:
../sysdeps/i386/i486/bits/string.h: Â ôóíêöèè __mempcpy_by2
../sysdeps/i386/i486/bits/string.h:755: îøèáêà: can't find a register in class
GENERAL_REGS while reloading asm
../sysdeps/i386/i486/bits/string.h:755: îøèáêà: asm operand has impossible
constraints
make[2]: *** [/usr/src/rpm/BUILD/glibc-build/string/string-inlines.os] Îøèáêà 1
This is i486 string op. Is it too old and should be rewritten for i686? Got no
glue here. If you need preprocessed source I will attach this.
So far, the piece of code leading to the fail is:
__STRING_INLINE char *
__mempcpy_by2 (char *__dest, __const char *__src, size_t __srclen)
{
register char *__tmp = __dest;
register unsigned long int __d0, __d1;
__asm__ __volatile__
(shrl $1,%3\n\t
jz2f\n /* only a word */
1:\n\t
movl (%2),%0\n\t
leal 4(%2),%2\n\t
movl %0,(%1)\n\t
leal 4(%1),%1\n\t
decl %3\n\t
jnz 1b\n
2:\n\t
movw (%2),%w0\n\t
movw %w0,(%1)
: =q (__d0), =r (__tmp), =r (__src), =r (__d1),
=m ( *(struct { __extension__ char __x[__srclen]; } *)__dest)
: 1 (__tmp), 2 (__src), 3 (__srclen / 2),
m ( *(struct { __extension__ char __x[__srclen]; } *)__src)
: cc);
return __tmp + 2;
}
--
Summary: i486 assembler bug (GLIBC 2.6) or feature?
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Vladislav dot Mikhailikov at paradox-neo dot uz
GCC build triplet: pentium4-east-linux
GCC host triplet: pentium4-east-linux
GCC target triplet: pentium4-east-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32818
[Bug target/32818] i486 assembler bug (GLIBC 2.6) or feature?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32818
[Bug libstdc++/32819] New: Hash Document Errors
from libstdc++-v3/docs/html/ext/pb_ds/hash_based_containers.html There might be 2 errors in the Hash Table Design document as follows: == 1st Error: Section : Hash Table Design - Implementation - Probing Tables Original text : gp_hash_table is parametrized by Hash_Fn, Probe_Fn, and Comb_Probe_Fn. As before, if Probe_Fn and Comb_Probe_Fn are, respectively, null_hash_fn and null_probe_fn, then Comb_Probe_Fn is a ranged-probe functor. ... Suggestion text: gp_hash_table is parametrized by Hash_Fn, Probe_Fn, and Comb_Probe_Fn. As before, if Hash_Fn and Probe_Fn are, respectively, null_hash_fn and null_probe_fn, then Comb_Probe_Fn is a ranged-probe functor. ... == 2nd Error: Figure: Hash policy class diagram. Suggestion: null_probe_fn class is missing. == I have to apologize if they are not errors. I am quite new to this forum and my english is very poor. Chalathip Thumkanon. -- Summary: Hash Document Errors Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chalathip at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32819
[Bug c/32820] New: optimizer malfunction when mixed with asm statements
The below C code is a stripped down version of some code generated
by the GHC Haskell compiler. When it is compiled with -O, incorrect
code is generated. The Hp variable should live in %r7 but the compiled
routine does not set %r7. It does set it when -O is omitted.
I checked a few versions of gcc and the problem is present in at least
the following versions:
3.0.2
3.1.1
3.2.3
3.3.6
3.4.6
4.0.1
4.0.4
4.1.2
compile line:
gcc -O -o temp.s -x c temp.i -fno-strict-aliasing -S
input file:
typedef signed char StgInt8;
typedef unsigned char StgWord8;
typedef signed short StgInt16;
typedef unsigned short StgWord16;
typedef signed int StgInt32;
typedef unsigned int StgWord32;
typedef signed long long int StgInt64;
typedef unsigned long long int StgWord64;
typedef StgInt32 StgInt;
typedef StgWord32 StgWord;
typedef StgInt16 StgHalfInt;
typedef StgWord16 StgHalfWord;
typedef void* StgAddr;
typedef StgWord32 StgChar;
typedef int StgBool;
typedef float StgFloat;
typedef double StgDouble;
typedef void StgVoid;
typedef struct StgClosure_ StgClosure;
typedef StgClosure* StgClosurePtr;
typedef StgWord* StgPtr;
typedef StgWord StgOffset;
typedef struct StgTSO_* StgTSOPtr;
typedef void* StgForeignPtr;
typedef StgInt StgStackOffset;
typedef StgWord* StgStackPtr;
typedef StgWord8 StgCode;
typedef StgPtr* StgArray;
typedef char* StgByteArray;
typedef void* StgStablePtr;
typedef void *(*(*StgFunPtr)(void))(void);
typedef StgFunPtr StgFun(void);
typedef StgChar C_;
typedef StgWord W_;
typedef StgWord* P_;
typedef P_* PP_;
typedef StgInt I_;
typedef StgAddr A_;
typedef const StgWord* D_;
typedef StgFunPtr F_;
typedef StgByteArray B_;
typedef StgClosurePtr L_;
typedef StgInt64 LI_;
typedef StgWord64 LW_;
typedef struct {
StgFunPtr stgGCEnter1;
StgFunPtr stgGCFun;
} StgFunTable;
typedef union {
StgWord w;
StgAddr a;
StgChar c;
StgInt8 i8;
StgInt i;
StgPtr p;
StgClosurePtr cl;
StgStackOffset offset;
StgByteArray b;
StgTSOPtr t;
} StgUnion;
typedef struct StgRegTable_ {
StgUnion rR1;
StgUnion rR2;
StgUnion rR3;
StgUnion rR4;
StgUnion rR5;
StgUnion rR6;
StgUnion rR7;
StgUnion rR8;
StgUnion rR9;
StgUnion rR10;
StgFloat rF1;
StgFloat rF2;
StgFloat rF3;
StgFloat rF4;
StgDouble rD1;
StgDouble rD2;
StgWord64 rL1;
StgPtr rSp;
StgPtr rSpLim;
StgPtr rHp;
StgPtr rHpLim;
struct StgTSO_ *rCurrentTSO;
struct bdescr_ *rNursery;
struct bdescr_ *rCurrentNursery;
StgWord rHpAlloc;
} StgRegTable;
typedef struct Capability_ {
StgFunTable f;
StgRegTable r;
} Capability;
extern W_ MainCapability[];
register P_ Sp __asm__(% r4);
register P_ SpLim __asm__(% r6);
register P_ Hp __asm__(% r7);
register P_ HpLim __asm__(% r8);
F_ stg_returnToStackTop(void) {
W_ _c2;
_c2 = (W_)Capability *)MainCapability)[0].r)-rCurrentTSO);
Sp = (P_)(*((P_)(_c2+52)));
SpLim = (P_)(_c2+140);
Hp = (P_)((*((P_)((W_)Capability
*)MainCapability)[0].r)-rCurrentNursery)+4))) + (-0x4U));
HpLim = (P_)((*((P_)((W_)Capability
*)MainCapability)[0].r)-rCurrentNursery +
(I_)(*((P_)((W_)Capability
*)MainCapability)[0].r)-rCurrentNursery)+24) * 0x1000U) + (-0x1U)));
do { void *_procedure = (void *)(*((P_)((W_)Sp + (0x0 * 0x4U; if (((int)
_procedure) 2) _procedure = (void *)(*((int *) (_procedure - 2))); goto
*_procedure; } while(0);
}
--
Summary: optimizer malfunction when mixed with asm statements
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbuehler at spirentcom dot com
GCC build triplet: hppa1.0-hp-hpux11.00
GCC host triplet: hppa1.0-hp-hpux11.00
GCC target triplet: hppa1.0-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820
[Bug middle-end/32761] [4.3 Regression] build broke: var_tracking loses track of register elimination, crashes in find_src_set_src on parallel set
--- Comment #4 from rask at sygehus dot dk 2007-07-19 13:31 --- Created an attachment (id=13939) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13939action=view) Test case for frv-unknown-elf with -O2 -g -mcpu=fr400 It breaks on frv-unknown-elf as well: Program received signal SIGSEGV, Segmentation fault. find_src_set_src (set=0xdf05a0, loc=0x2b2c3b921760, insn=value optimized out) at /n/12/rask/src/all/gcc/var-tracking.c:1865 1865 if (REG_P (src)) (gdb) call debug_rtx(src) (nil) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32761
[Bug tree-optimization/32821] New: tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
#0 first_stmt (bb=0xb7fa75a0) at ../../gcc/gcc/tree-iterator.h:43 #1 0x0838d46e in dump_generic_bb (file=0x9785710, bb=0xb7fa75a0, indent=0, flags=16448) at ../../gcc/gcc/tree-pretty-print.c:2909 #2 0x0831b8a7 in tree_dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at ../../gcc/gcc/tree-cfg.c:2206 #3 0x08127144 in dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at ../../gcc/gcc/cfghooks.c:294 #4 0x08324f4e in remove_bb (bb=0xb7fa75a0) at ../../gcc/gcc/tree-cfg.c:1964 #5 0x0812661d in delete_basic_block (bb=0xb7fa75a0) at ../../gcc/gcc/cfghooks.c:472 #6 0x0835ad2a in combine_blocks (loop=0xb7d73678) at ../../gcc/gcc/tree-if-conv.c:991 #7 0x0835bb2d in tree_if_conversion (loop=0xb7d73678, for_vectorizer=value optimized out) at ../../gcc/gcc/tree-if-conv.c:201 #8 0x0835c813 in main_tree_if_conversion () at ../../gcc/gcc/tree-if-conv.c:1137 #9 0x0829768f in execute_one_pass (pass=0x8823060) at ../../gcc/gcc/passes.c:1125 #10 0x0829788f in execute_pass_list (pass=0x8823060) at ../../gcc/gcc/passes.c:1178 #11 0x082978a2 in execute_pass_list (pass=0x88239a0) at ../../gcc/gcc/passes.c:1179 #12 0x082978a2 in execute_pass_list (pass=0x88231a0) at ../../gcc/gcc/passes.c:1179 #13 0x08375fc2 in tree_rest_of_compilation (fndecl=0xb7d66f00) at ../../gcc/gcc/tree-optimize.c:406 #14 0x084e8da0 in cgraph_expand_function (node=0xb7d66f80) at ../../gcc/gcc/cgraphunit.c:1073 #15 0x084eb500 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1142 #16 0x0805ddd6 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7898 #17 0x0831996f in toplev_main (argc=17, argv=0xbfced724) at ../../gcc/gcc/toplev.c:1057 #18 0x080da95f in main (argc=-1210635284, argv=0xb7d72c24) at ../../gcc/gcc/main.c:35 -- Summary: tree-if-conv:combine_blocks with -ftree-dump-tree-all- details fails on ICE in compilation: segfault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tehila at il dot ibm dot com GCC build triplet: i386-redhat-linux (also powerpc-*-linux) GCC host triplet: i386-redhat-linux (also powerpc-*-linux) GCC target triplet: i386-redhat-linux (also powerpc-*-linux) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug tree-optimization/32821] tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
--- Comment #1 from tehila at il dot ibm dot com 2007-07-19 13:38 ---
(In reply to comment #0)
#0 first_stmt (bb=0xb7fa75a0) at ../../gcc/gcc/tree-iterator.h:43
#1 0x0838d46e in dump_generic_bb (file=0x9785710, bb=0xb7fa75a0, indent=0,
flags=16448) at ../../gcc/gcc/tree-pretty-print.c:2909
#2 0x0831b8a7 in tree_dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at
../../gcc/gcc/tree-cfg.c:2206
#3 0x08127144 in dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at
../../gcc/gcc/cfghooks.c:294
#4 0x08324f4e in remove_bb (bb=0xb7fa75a0) at ../../gcc/gcc/tree-cfg.c:1964
#5 0x0812661d in delete_basic_block (bb=0xb7fa75a0) at
../../gcc/gcc/cfghooks.c:472
#6 0x0835ad2a in combine_blocks (loop=0xb7d73678) at
../../gcc/gcc/tree-if-conv.c:991
#7 0x0835bb2d in tree_if_conversion (loop=0xb7d73678, for_vectorizer=value
optimized out) at ../../gcc/gcc/tree-if-conv.c:201
#8 0x0835c813 in main_tree_if_conversion () at
../../gcc/gcc/tree-if-conv.c:1137
#9 0x0829768f in execute_one_pass (pass=0x8823060) at
../../gcc/gcc/passes.c:1125
#10 0x0829788f in execute_pass_list (pass=0x8823060) at
../../gcc/gcc/passes.c:1178
#11 0x082978a2 in execute_pass_list (pass=0x88239a0) at
../../gcc/gcc/passes.c:1179
#12 0x082978a2 in execute_pass_list (pass=0x88231a0) at
../../gcc/gcc/passes.c:1179
#13 0x08375fc2 in tree_rest_of_compilation (fndecl=0xb7d66f00) at
../../gcc/gcc/tree-optimize.c:406
#14 0x084e8da0 in cgraph_expand_function (node=0xb7d66f80) at
../../gcc/gcc/cgraphunit.c:1073
#15 0x084eb500 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1142
#16 0x0805ddd6 in c_write_global_declarations () at
../../gcc/gcc/c-decl.c:7898
#17 0x0831996f in toplev_main (argc=17, argv=0xbfced724) at
../../gcc/gcc/toplev.c:1057
#18 0x080da95f in main (argc=-1210635284, argv=0xb7d72c24) at
../../gcc/gcc/main.c:35
(In reply to comment #0)
#0 first_stmt (bb=0xb7fa75a0) at ../../gcc/gcc/tree-iterator.h:43
#1 0x0838d46e in dump_generic_bb (file=0x9785710, bb=0xb7fa75a0, indent=0,
flags=16448) at ../../gcc/gcc/tree-pretty-print.c:2909
#2 0x0831b8a7 in tree_dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at
../../gcc/gcc/tree-cfg.c:2206
#3 0x08127144 in dump_bb (bb=0xb7fa75a0, outf=0x9785710, indent=0) at
../../gcc/gcc/cfghooks.c:294
#4 0x08324f4e in remove_bb (bb=0xb7fa75a0) at ../../gcc/gcc/tree-cfg.c:1964
#5 0x0812661d in delete_basic_block (bb=0xb7fa75a0) at
../../gcc/gcc/cfghooks.c:472
#6 0x0835ad2a in combine_blocks (loop=0xb7d73678) at
../../gcc/gcc/tree-if-conv.c:991
#7 0x0835bb2d in tree_if_conversion (loop=0xb7d73678, for_vectorizer=value
optimized out) at ../../gcc/gcc/tree-if-conv.c:201
#8 0x0835c813 in main_tree_if_conversion () at
../../gcc/gcc/tree-if-conv.c:1137
#9 0x0829768f in execute_one_pass (pass=0x8823060) at
../../gcc/gcc/passes.c:1125
#10 0x0829788f in execute_pass_list (pass=0x8823060) at
../../gcc/gcc/passes.c:1178
#11 0x082978a2 in execute_pass_list (pass=0x88239a0) at
../../gcc/gcc/passes.c:1179
#12 0x082978a2 in execute_pass_list (pass=0x88231a0) at
../../gcc/gcc/passes.c:1179
#13 0x08375fc2 in tree_rest_of_compilation (fndecl=0xb7d66f00) at
../../gcc/gcc/tree-optimize.c:406
#14 0x084e8da0 in cgraph_expand_function (node=0xb7d66f80) at
../../gcc/gcc/cgraphunit.c:1073
#15 0x084eb500 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1142
#16 0x0805ddd6 in c_write_global_declarations () at
../../gcc/gcc/c-decl.c:7898
#17 0x0831996f in toplev_main (argc=17, argv=0xbfced724) at
../../gcc/gcc/toplev.c:1057
#18 0x080da95f in main (argc=-1210635284, argv=0xb7d72c24) at
../../gcc/gcc/main.c:35
Sorry, missed this info:
The testcase is very simple:
void main1(int *arr, int n, int a, int b)
{
int i;
for (i = 0; i n; i++)
{
int m = arr[i];
arr[i] = (m a ? m-a : b);
}
}
It fails while trying to delete a basic-block that is unnecessary after
tree-if-conversion (on the dump command before the deletion).
2 comments:
1. It doesn't happen without the '-details' (-fdump-tree-all-details).
2. It fails only with -ftree-vectorize on (this is the only way to turn on the
tree-if-conversion).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug tree-optimization/32821] tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
--- Comment #2 from tehila at il dot ibm dot com 2007-07-19 13:51 ---
(In reply to comment #1)
I've just tried to comment out the code:
if (dump_flags TDF_DETAILS)
{
dump_bb (bb, dump_file, 0);
fprintf (dump_file, \n);
}
from tree-cfg.c (at the beginning of remove_bb function, lines: 1962-1966).
Without this code it compiles OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug tree-optimization/32821] tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
--- Comment #3 from ubizjak at gmail dot com 2007-07-19 13:56 --- (In reply to comment #1) It fails while trying to delete a basic-block that is unnecessary after tree-if-conversion (on the dump command before the deletion). No, it ICEs when empty BB is to be pretty-printed. A tree pretty-printer should be fixed/updated for this situation, this is all this PR is about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug tree-optimization/32821] tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
--- Comment #4 from tehila at il dot ibm dot com 2007-07-19 14:15 --- No, it ICEs when empty BB is to be pretty-printed. A tree pretty-printer should be fixed/updated for this situation, this is all this PR is about. Thanks for the quick response. You're right, since the if-conversion cleans the BB before deleting it ( Remove labels and make stmts member of loop-header.). Any way, does anyone see this problem in other passes, besides tree-if-conv? Might be it's the only pass to expose this problem? And also, why do we need to (pretty-)print empty BB? I guess we can solve this problem either by changing this dump in pretty-print (or in the tree-cfg dumps) or have another similar function of remove_bb (like remove_empty_bb). -- tehila at il dot ibm dot com changed: What|Removed |Added CC||tehila at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug libstdc++/32822] New: More Hash Document Errors
+++ This bug was initially created as a clone of Bug #32819 +++
from libstdc++-v3/docs/html/ext/pb_ds/hash_based_containers.html
In the Bug #32819, I report 2 errors. But I found one more bug.
Section : Hash Table Design - Hash Policies - Ranged-Hash Functions
Original text :
Now assume that s is the string representation of a of a long DNA sequence (and
so S = {'A', 'C', 'G', 'T'}). In this case, scanning the entire string might be
prohibitively expensive. A possible alternative might be to use only the first
k characters of the string, where
k^|S| #8805; m -- (1)
...
requiring scanning over only
k = log4( m ) -- (2)
characters.
My suggestion:
In my humble opinion, I think that the first equation should be changed to
|S|^k #8805; m
Otherwise, the second equation should be changed to
k=m^(1/4)
Anyway if the form of the second equation is changed from
k = xxx
to
k = integral_ceiling (xxx)
or something looks like
k= [xxx] ,(but the brackets should have only their upper halves ),
it might be a little more accurate.
Best regards,
Chalathip Thumkanon.
--
Summary: More Hash Document Errors
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chalathip at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32822
[Bug fortran/32823] New: internal compiler error: in gfc_trans_assignment_1
This error came up during a rebuild of my program - [dranta:~/sage/sage20070104] dir% gfortran -c -O0 -fno-second-underscore token.f90 token.f90: In function 'token_allreduce_i8_v': token.f90:7: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3974 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [dranta:~/sage/sage20070104] dir% cat token.f90 module token_module integer, parameter :: INT8 = SELECTED_INT_KIND(16) integer, parameter :: REAL8 = SELECTED_REAL_KIND(12) contains subroutine token_allreduce_i8_v(dowhat, array, result, length) character(*), intent(in):: dowhat integer, intent(in):: length integer(INT8), intent(in):: array(*) integer(INT8), intent(inout) :: result(*) real(REAL8) :: copy_r8(length), result_r8(length) result(1:length) = int(result_r8(1:length), INT8) end subroutine token_allreduce_i8_v ! -- end module token_module ! == [dranta:~/sage/sage20070104] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-bootstrap --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070719 (experimental) -- Summary: internal compiler error: in gfc_trans_assignment_1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32823
[Bug fortran/32715] improve diagnostics of attempted allocation of non-array
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 16:30 --- In gfc_match_allocate m = gfc_match_variable (tail-expr, 0); matches successfully, but it fails at: if (gfc_match ( )%t) != MATCH_YES) goto syntax; As i is scalar, it does not seem to match the (4) (or only partially) and thus it does not match )%t. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32715
[Bug fortran/32823] [4.3 regression] internal compiler error: in gfc_trans_assignment_1
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-19 16:38 --- Confirmed. Reduced testcase: $ cat pr32823.f90 integer(8) :: res(3) res = int((/ 1.0, 2.0, 3.0 /), 8) end $ gfortran-svn pr32823.f90 pr32823.f90: In function 'MAIN__': pr32823.f90:1: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3936 Backtrace: (gdb) bt #0 fancy_abort (file=0x873bdf8 ../../../gcc/gcc/fortran/trans-expr.c, line=3936, function=0x873c161 gfc_trans_assignment_1) at ../../../gcc/gcc/diagnostic.c:655 #1 0x080ddd48 in gfc_trans_assignment_1 (expr1=0x88f93c8, expr2=0x8934c98, init_flag=0 '\0') at ../../../gcc/gcc/fortran/trans-expr.c:3935 #2 0x080de0f5 in gfc_trans_assignment (expr1=0x88f93c8, expr2=0x8934c98, init_flag=53 '5') at ../../../gcc/gcc/fortran/trans-expr.c:4064 #3 0x080dedd1 in gfc_trans_assign (code=0x8934f70) at ../../../gcc/gcc/fortran/trans-expr.c:4076 #4 0x080beb26 in gfc_trans_code (code=0x8934f70) at ../../../gcc/gcc/fortran/trans.c:566 #5 0x080d58b2 in gfc_generate_function_code (ns=0x8933e08) at ../../../gcc/gcc/fortran/trans-decl.c:3275 #6 0x080937fd in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3286 #7 0x080b8bdd in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:301 #8 0x0832a820 in toplev_main (argc=2, argv=0xbfac6084) at ../../../gcc/gcc/toplev.c:1044 #9 0x080ff78f in main (argc=Cannot access memory at address 0x35 Probably related: $ cat pr32823_1.f90 print *, int((/ 1.0, 2.0, 3.0 /), 4) end $ gfortran-svn pr32823_1.f90 pr32823_1.f90: In function 'MAIN__': pr32823_1.f90:1: internal compiler error: in gfc_trans_transfer, at fortran/trans-io.c:2017 Removing the kind specifier from INT() hides the problem. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.10.0 | Known to fail||4.3.0 Known to work||4.2.1 Last reconfirmed|-00-00 00:00:00 |2007-07-19 16:38:27 date|| Summary|internal compiler error: in |[4.3 regression] internal |gfc_trans_assignment_1 |compiler error: in ||gfc_trans_assignment_1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32823
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-19 16:50 --- The IL representation is not a thing to complain about. Do you have a testcase that shows a missed optimization instead of a one that has IL that is different from what you expect? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32824] New: Missed reduction vectorizer after store to global is LIM'd
Testcase:
int a[16*100];
int e;
float f(void)
{
int i;
for(i = 0;i16*100;i++)
e += a[i];
}
rt.c:7: note: not vectorized: unsupported use in stmt.
If I manually LIM'd e, then this is vectorized.
--
Summary: Missed reduction vectorizer after store to global is
LIM'd
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: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
[Bug tree-optimization/32825] New: Reduction with nonzero start (arbitrary also) causes an extra add to happen
Testcase (Compile at -O2 -maltivec -ftree-vectorize):
int a[16*100];
int f(int e)
{
int i;
for(i = 0;i16*100;i++)
e += a[i];
return e;
}
- Cut -
Currently we get:
ivtmp.42 = (long unsigned int) a;
vect_var_.36 = { 0, 0, 0, 0 };
bb 3:
vect_var_.36 = MEM[index: ivtmp.42] + vect_var_.36;
ivtmp.42 = ivtmp.42 + 16;
if (ivtmp.42 != (long unsigned int) (a + 6400))
goto bb 3;
else
goto bb 4;
bb 4:
vect_var_.39 = vect_var_.36 v 64;
vect_var_.47 = vect_var_.39 + vect_var_.36;
vect_var_.48 = vect_var_.47 v 32;
stmp_var_.38 = BIT_FIELD_REF vect_var_.48 + vect_var_.47, 32, 96;
return stmp_var_.38 + e;
Though the last add is extra and does not need to be done, we can get rid of it
by having vect_var_.36 being set initially to {e, 0, 0, 0} .
Note this happens with a non zero start also, that is:
int a[16*100];
int f(int e)
{
int i;
e = 1;
for(i = 0;i16*100;i++)
e += a[i];
return e;
}
--
Summary: Reduction with nonzero start (arbitrary also) causes an
extra add to happen
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: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825
[Bug tree-optimization/32826] New: Reduction into a global variable causes a Load Hit Store Hazard (for the Cell)
Testcase (compile at -O2 -maltivec -ftree-vectorize):
int a[16*100];
int e;
float f(void)
{
int i;
int e1;
e1 = e;
for(i = 0;i16*100;i++)
e1 += a[i];
e = e1;
}
--- cut --
Currently you get:
stvewx v1,0,r2
lis r2,ha16(_e)
lwz r0,-20(r1) LHS hazard
stw r0,lo16(_e)(r2)
Even though the elements of v1 will all be the same, so GCC could do:
lis r2,ha16(_e)
add r2, lo16(_e)(r2)
stvewx v1,0,r2
--
Summary: Reduction into a global variable causes a Load Hit Store
Hazard (for the Cell)
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: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32826
[Bug tree-optimization/32826] Reduction into a global variable causes a Load Hit Store Hazard (for the Cell)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-19 17:15 ---
Note I copied the wrong testcase, the correct testcase is:
int a[16*100];
int e;
float f(void)
{
int i;
int e1;
e1 = 0;
for(i = 0;i16*100;i++)
e1 += a[i];
e = e1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32826
[Bug middle-end/32791] missed optimization after inline functions with multiple return statements
--- Comment #2 from manuelle at ee dot ethz dot ch 2007-07-19 17:51 --- Created an attachment (id=13940) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13940action=view) test cases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32791
[Bug middle-end/32791] missed optimization after inline functions with multiple return statements
--- Comment #3 from manuelle at ee dot ethz dot ch 2007-07-19 17:52 --- hmm, I'm not sure if that is the same problem. your testcase from bug 32810 does the right thing on x86. in the attached file containing all three functions func1 and func3 produce the same code, only code produced for func2 is terrible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32791
[Bug middle-end/32791] missed optimization after inline functions with multiple return statements
--- Comment #4 from pinskia at gmail dot com 2007-07-19 17:56 --- Subject: Re: missed optimization after inline functions with multiple return statements On 19 Jul 2007 17:52:14 -, manuelle at ee dot ethz dot ch [EMAIL PROTECTED] wrote: your testcase from bug 32810 does the right thing on x86. Yes I know it works overall but the tree level optimizer does not do it, -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32791
[Bug tree-optimization/32806] Missing optimization to remove backword dependencies
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-19 18:07 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-19 18:07:11 date|| Summary|Missing optimization to |Missing optimization to |remove backword dependencies|remove backword dependencies http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32806
[Bug tree-optimization/32810] Not folding of const element for goto
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-19 18:08 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-19 18:08:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32810
[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:09 --- I think this is similar to PR19347? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
[Bug fortran/32823] [4.3 regression] internal compiler error: in gfc_trans_assignment_1
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-07-19 18:10 --- Mine. Caused by my recent intrinsic handling changes. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-19 16:38:27 |2007-07-19 18:10:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32823
[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 18:14 --- (In reply to comment #1) I think this is similar to PR19347? It is not because LIM does its work, IR right before the vectorizer: bb 3: # ivtmp.31_17 = PHI ivtmp.31_18(4), 1600(2) # e_lsm.30_1 = PHI e_lsm.30_13(4), e_lsm.30_8(2) # i_14 = PHI i_7(4), 0(2) D.2248_4 = a[i_14]; e.1_5 = e_lsm.30_1; e.2_6 = D.2248_4 + e.1_5; e_lsm.30_13 = e.2_6; i_7 = i_14 + 1; ivtmp.31_18 = ivtmp.31_17 - 1; if (ivtmp.31_18 != 0) There are no loads from e in the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:15 ---
...
Though the last add is extra and does not need to be done, we can get rid of
it
by having vect_var_.36 being set initially to {e, 0, 0, 0} .
The problem is that often initializing a vector to {e, 0, 0, 0} is (much?) more
expensive than initializing a vector to {0, 0, 0, 0} and then adding e to the
final scalar result. We actually had both options in the vectorizer for a while
(guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how to
choose between the two options (cost wise), so we just arbitrarily chose one.
Now that we're starting to build a cost model we may try to evaluate which of
the two options to generate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #13 from zippel at gcc dot gnu dot org 2007-07-19 18:27 ---
The initial test case is part of the missed optimization. For example current
stable Debian gcc (4.1.2 20061115) produces code like this:
movl4(%esp), %eax
movl8(%esp), %edx
leal(%eax,%edx,4), %edx
movl4(%edx), %ecx
movl8(%edx), %eax
addl%ecx, %eax
movl12(%edx), %ecx
addl%ecx, %eax
ret
Which has some unnecessaries moves, but it shows the basic idea, so with
eliminated moves it would be:
movl4(%esp), %eax
movl8(%esp), %edx
leal(%eax,%edx,4), %edx
movl4(%edx), %eax
addl8(%edx), %eax
addl12(%edx), %eax
ret
From the code size this is identical to:
movl4(%esp), %ecx
movl8(%esp), %edx
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
addl12(%ecx,%edx,4), %eax
ret
But it depends now on the target which instruction sequence is better.
The problem is now with the new canonical form, that AFAICT it has become
practically very difficult to generate the optimal sequence based on
instruction costs.
The older gcc produces this IL before RTL generation:
D.1283 = (int *) (i * 4) + p;
return *(D.1283 + 4B) + *(D.1283 + 8B) + *(D.1283 + 12B);
which produces far better RTL for the optimizers to work with.
BTW this problem is not limited to pointer expression, since the lea
instruction is used in other expressions as well.
Let's take this example:
void f(unsigned int *p, unsigned int a)
{
p[0] = a * 4 + 4;
p[1] = a * 4 + 8;
p[2] = a * 4 + 12;
}
Above gcc 4.1 produces this:
D.1281 = a * 4;
*p = D.1281 + 4;
*(p + 4B) = D.1281 + 8;
*(p + 8B) = D.1281 + 12;
movl8(%esp), %eax
movl4(%esp), %ecx
sall$2, %eax
leal4(%eax), %edx
movl%edx, (%ecx)
leal8(%eax), %edx
addl$12, %eax
movl%edx, 4(%ecx)
movl%eax, 8(%ecx)
ret
gcc 4.2 produces this:
*p = (a + 1) * 4;
D.1545 = a * 4;
*(p + 4B) = D.1545 + 8;
*(p + 8B) = D.1545 + 12;
movl8(%esp), %eax
movl4(%esp), %ecx
leal4(,%eax,4), %edx
sall$2, %eax
movl%edx, (%ecx)
leal8(%eax), %edx
addl$12, %eax
movl%edx, 4(%ecx)
movl%eax, 8(%ecx)
ret
So 4.2 already produces slightly worse code.
Current gcc finally produces:
*p = (a + 1) * 4;
*(p + 4) = (a + 2) * 4;
*(p + 8) = (a + 3) * 4;
movl8(%esp), %eax
movl4(%esp), %ecx
leal4(,%eax,4), %edx
movl%edx, (%ecx)
leal8(,%eax,4), %edx
leal12(,%eax,4), %eax
movl%edx, 4(%ecx)
movl%eax, 8(%ecx)
ret
This has now the largest code size of all versions.
This new canonical form IMHO clearly conflicts with what is expected at RTL
level, so I don't understand why it's so important to use this one. Could you
maybe explain the reason behind this choice?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-19 18:28 --- ah, I misunderstood you - when you wrote before that you manually LIM'd e I assumed it was because LIM didn't work. I see that the problem is with the garbage that LIM leaves behind: pr32824.c:6: note: Analyze phi: e_lsm.30_1 = PHI e_lsm.30_13(4), e_lsm.30_8(2)pr32824.c:6: note: Unknown def-use cycle pattern. ... pr32824.c:6: note: def_stmt: e_lsm.30_1 = PHI e_lsm.30_13(4), e_lsm.30_8(2) pr32824.c:6: note: Unsupported pattern. pr32824.c:6: note: not vectorized: unsupported use in stmt. We may have a PR for cleaning up redundant phis (or teach the vectorizer to ignore them) - I'll try to look for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-19 18:32 ---
The problem is that often initializing a vector to {e, 0, 0, 0} is (much?)
more
On SPU, it is not:
cwd $2,0($sp)
shufb $5,$3,$5,$2
vs:
ori $7,$3,0
il $5,0
...
a $8,$9,$7
Also it increases register pressure by long gating incomming argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825
[Bug fortran/32814] backslash zero no longer writes null in string
--- Comment #2 from jhettmer at doprad dot com 2007-07-19 19:04 --- Subject: Re: backslash zero no longer writes null in string Thanks. Will do. jvdelisle at gcc dot gnu dot org wrote: --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-19 02:10 --- This bug has been fixed in 4.3. This was pr32223. There are no plans to back port this at the moment. Have you tried using binaries for 4.3 from Fortran wiki? Or build it youself? *** This bug has been marked as a duplicate of 32223 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32814
[Bug fortran/32804] ISO C Binding: C_LOC argument checking needs improvement
--- Comment #2 from patchapp at dberlin dot org 2007-07-19 19:15 --- Subject: Bug number PR 32804 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01577.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32804
[Bug target/32276] [4.3 Regression]: libmudflap.c++/pass41-frag.cxx
--- Comment #3 from hjl at lucon dot org 2007-07-19 19:19 --- Jan, we verified that your patch http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00538.html caused this regression. Can you take a look? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug libstdc++/32819] pb_ds/hash_based_containers.html errors
-- pcarlini at suse dot de changed: What|Removed |Added URL|http://gcc.gnu.org/onlinedoc| |s/libstdc++/ext/pb_ds/hash_b| |ased_containers.html| Severity|normal |minor Summary|Hash Document Errors|pb_ds/hash_based_containers. ||html errors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32819
[Bug libstdc++/32822] More pb_ds/hash_based_containers.html errors
-- pcarlini at suse dot de changed: What|Removed |Added URL|http://gcc.gnu.org/onlinedoc| |s/libstdc++/ext/pb_ds/hash_b| |ased_containers.html| Severity|normal |minor Summary|More Hash Document Error|More ||pb_ds/hash_based_containers. ||html errors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32822
[Bug fortran/32738] Error: Function 'tree_size' at (1) has no IMPLICIT type
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-19 21:11 --- Subject: Bug 32738 Author: dfranke Date: Thu Jul 19 21:11:38 2007 New Revision: 126790 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126790 Log: 2007-07-19 Daniel Franke [EMAIL PROTECTED] PR fortran/32738 * gfortran.dg/pr32768.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr32738.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32738
[Bug fortran/32738] Error: Function 'tree_size' at (1) has no IMPLICIT type
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-19 21:12 --- Assuming fixed. Added the testcase to the testsuite (r126790). Closing as WORKSFORME. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32738
[Bug fortran/32827] New: IMPORT fails for TYPE when also used in INTERFACE
I created a program to invoke POSIX's gettimeofday using BIND(C) and encountered a compile-time problem. In searching the bug database, I discovered 30922, which exhibited a similar problem (now fixed). I managed to recreate my problem in a variant of the test program for 30922, so I am submitting that program instead in the hope that it is simpler and may be more familiar. The basic problem arises if I take the 30922 test program, convert it from a module to a program and then add a declaration for a TYPE'd variable. I have further simplified the test program, but I have also left the original 30922 test program in comments. The test program is: ! Original test program is from bug 30922. ! module test_import program test_import implicit none type :: my_type integer :: data end type my_type interface ! integer function func1(param) subroutine func1(param) import :: my_type type(my_type) :: param ! end function func1 end subroutine func1 ! integer function func2(param) !import :: my_type !type(my_type), value :: param ! end function func2 end interface ! end module test_import type(my_type) :: x ! this declaration causes the problem end program test_import The error message is: test_import.f:25.20: type(my_type) :: x ! this declaration causes the problem 1 test_import.f:7.17: type :: my_type 2 Error: The type my_type cannot be host associated at (1) because it is blocked by an incompatible object of the same name at (2) I believe that it is legal Fortran 2003 to incorporate INTERFACE declarations immediately within a program, but I could be mistaken. -- Summary: IMPORT fails for TYPE when also used in INTERFACE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sysmaint at contek dot com GCC build triplet: same - but with bug fix for fortran/32801 included GCC host triplet: i386-portbld-freebsd6.2 -- 4.3.0 20070713 (experimental) GCC target triplet: same http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32827
[Bug tree-optimization/32828] New: Bootstrap comparison error -- VUSES info changed
Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1objplus-checksum.o differs Bootstrap comparison failure! ./fortran/trans-array.o differs ./build/genattrtab.o differs ./omega.o differs ./tree-cfg.o differs ./gcc.o differs A build error was introduced at r126568. This was corrected by r126595 but after this change we have the comparison error. I applied r126595 directly on r126568 and see the same error, so the fault wasn't introduced by an intermediate change. -- Summary: Bootstrap comparison error -- VUSES info changed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32828
[Bug tree-optimization/32828] Bootstrap comparison error -- VUSES info changed
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-19 23:49 --- Subject: Re: New: Bootstrap comparison error -- VUSES info changed For reference, I attached the difference in omega.o between stage 2 and 3. --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-19 23:49 --- Created an attachment (id=13941) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13941action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32828
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-07-20 00:37 --- Um, correction: fixed for C. The C++ frontend also has this problem. Working on a patch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-07-18 16:34:41 |2007-07-20 00:37:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug bootstrap/32829] New: CVS bootstrap failure with as: unrecognised option -Qy
A very old report from v2.97 seems very similar, but had no infomation about the cause - see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2034 Bootstrapping gcc fails with the error: /home/brian/public/gnu/arm-elf/install.unix/arm-elf/bin/as: unrecognised option `-Qy` Where ...arm-elf/bin/as is a current binutils cvs version just compiled The configure line is: ../src/configure --target=arm-elf --enable-interwork --enable-multilib --enable-languages=c --without-headers --prefix=/home/brian/public/gnu/arm-elf/install.unix The command that causes the error is: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-o build/genmodes.o ../../gcc/gcc/genmodes.c The pre-processed file is available at http://www.valvers.com/genmodes.i The output of adding -v -save-temps to the command is: [EMAIL PROTECTED]:~/public/gnu/gcc/build.unix/gcc$ gcc -v -save-temps -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-o build/genmodes.o ../../gcc/gcc/genmodes.c 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) /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -E -quiet -v -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DHAVE_CONFIG_H -DGENERATOR_FILE ../../gcc/gcc/genmodes.c -mtune=generic -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -fworking-directory -O2 -fpch-preprocess -o genmodes.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu ignoring nonexistent directory ../../gcc/gcc/build #include ... search starts here: #include ... search starts here: . build ../../gcc/gcc ../../gcc/gcc/../include ../../gcc/gcc/../libcpp/include ../../gcc/gcc/../libdecnumber ../../gcc/gcc/../libdecnumber/dpd ../libdecnumber /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.1.2/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed genmodes.i -quiet -dumpbase genmodes.c -mtune=generic -auxbase-strip build/genmodes.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -version -fno-common -fstack-protector -fstack-protector -o genmodes.s GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (i486-linux-gnu) compiled by GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4). GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48106 Compiler executable checksum: c0d954aeefbb96d795ff3f6b3b72ef51 as -V -Qy -o build/genmodes.o genmodes.s /home/brian/public/gnu/arm-elf/install.unix/arm-elf/bin/as: unrecognized option `-V' -- Summary: CVS bootstrap failure with as: unrecognised option -Qy Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brian dot sidebotham at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-none-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug bootstrap/32829] CVS bootstrap failure with as: unrecognised option -Qy
--- Comment #1 from brian dot sidebotham at gmail dot com 2007-07-20 01:20 --- Created an attachment (id=13942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13942action=view) Pre-processed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug c/32830] New: shared library create by hppa64-hp11.11 can't run.
shared library create by hppa64-hp11.11 can't run. work ok on gcc-3.4.6,buit failed on gcc4.1.2/4.2.1. some symbol required by the shared library could not be found. -- Summary: shared library create by hppa64-hp11.11 can't run. Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cnstar9988 at gmail dot com GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
[Bug bootstrap/32831] New: Some warning on bootstrap....
build/gengtype warning: structure `eh_range' used but not defined warning: structure `jdeplist_s' used but not defined warning: structure `java_lexer' used but not defined warning: structure `ZipDirectory' used but not defined warning: structure `VEC_cp_token_position_heap' used but not defined warning: structure `c_arg_info' used but not defined warning: structure `c_switch' used but not defined warning: structure `et_node' used but not defined warning: structure `loop' used but not defined warning: structure `ipa_reference_vars_info_d' used but not defined warning: structure `reg_info_def' used but not defined warning: structure `value_set' used but not defined warning: structure `eh_range' used but not defined warning: structure `jdeplist_s' used but not defined warning: structure `java_lexer' used but not defined warning: structure `ZipDirectory' used but not defined warning: structure `VEC_cp_token_position_heap' used but not defined warning: structure `c_arg_info' used but not defined warning: structure `c_switch' used but not defined warning: structure `et_node' used but not defined warning: structure `loop' used but not defined warning: structure `ipa_reference_vars_info_d' used but not defined warning: structure `reg_info_def' used but not defined warning: structure `value_set' used but not defined -- Summary: Some warning on bootstrap Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cnstar9988 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32831
[Bug bootstrap/32831] Some warning on bootstrap....
--- Comment #1 from cnstar9988 at gmail dot com 2007-07-20 02:27 --- insn-conditions.md tmp-recog.c ../../gcc-4_2-branch/gcc/config/i386/i386.md:18885: warning: operand 1 missing mode? ../../gcc-4_2-branch/gcc/config/i386/i386.md:18928: warning: operand 1 missing mode? /bin/sh ../../gcc-4_2-branch/gcc/../move-if-change tmp-recog.c insn-recog.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32831
[Bug tree-optimization/32828] Bootstrap comparison error -- VUSES info changed
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-20 02:34 --- probably related to the gc bug we are chasing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32828
[Bug c++/32832] New: Seg fault on member function that does not return a val
The following code shows the error...
#include vector
#include list
#include map
#include iostream
#include string
using namespace std;
class foo {
public:
vector string bar (vectorstring s) {
//nothing returned but g++ never complains
}
};
int main()
{
string strs[] = {a, b};
foo f;
f.bar(vectorstring(strs, strs + 2));
}
--
[EMAIL PROTECTED]:~/working/TC$ g++ -o g_bug g_bug.cpp
[EMAIL PROTECTED]:~/working/TC$ ./g_bug
Segmentation fault
--
#include vector
#include list
#include map
#include iostream
#include string
using namespace std;
class foo {
public:
vector string bar (vectorstring s) {
return vectorstring(); // fixes problem!?
}
};
int main()
{
string strs[] = {a, b};
foo f;
f.bar(vectorstring(strs, strs + 2));
}
-
[EMAIL PROTECTED]:~/working/TC$ g++ -o g_bug g_bug.cpp
[EMAIL PROTECTED]:~/working/TC$ ./g_bug
-
Note that with -Wall it warn, but will not report any error...
-
[EMAIL PROTECTED]:~/working/TC$ g++ -Wall -o g_bug g_bug.cpp
g_bug.cpp: In member function std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorcharfoo::bar(std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar ):
g_bug.cpp:12: warning: no return statement in function returning non-void
g_bug.cpp:12: warning: control reaches end of non-void function
I am using Ubuntu dapper with their version of gcc which I would assume to be
pretty up to date. Sorry if this is a repeat, I didn't quite know how to search
for this particular bug since it occurs at run time.
--
Summary: Seg fault on member function that does not return a val
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: CyrusOmega at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32832
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug debug/31899] [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/16876] [4.0/4.1/4.2 Regression] ICE on testcase with -O3 in fold-const
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug driver/14435] [4.0/4.1/4.2/4.3 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug c++/23287] [4.0/4.1/4.2/4.3 regression] Explicitly invoking destructor of template class in a template and is dependent
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug testsuite/28870] [4.2/4.3 Regression] configuring, over-riding timeout values in testsuite
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug c++/29000] [4.2/4.3 regression] ICE on invalid use of template in statement-expr
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/29256] [4.2/4.3 regression] loop performance regression
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug c++/29363] [4.2/4.3 regression] ICE throwing undeclared object
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug c++/32108] [4.2/4.3 regression] ICE with __label__ outside of block scope
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32108
[Bug testsuite/27707] g++.dg/tree-ssa/ivopts-1.C fails
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
[Bug c++/27084] Does not propagate memory load base through useless type conversion
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug c++/30299] [4.2/4.3 regression] ICE with broken template and inheritance
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug c/29129] [4.2/4.3 Regression] [DR needed] unnamed parameters using [*]
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug target/22553] [4.1/4.2/4.3 regression] ICE building libstdc++
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug c++/31747] [4.2/4.3 regression] ICE combining static and extern
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
[Bug target/28583] [4.2/4.3 regression] ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
[Bug bootstrap/27367] [4.2/4.3 Regression] gstdint.h in libdecnumber is not cleaned up with make distclean
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
[Bug c/26154] OpenMP extensions to the C language is not documented or doumented in the wrong spot
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug middle-end/24998] [4.2/4.3 Regression] Build failure: undefined symbol __floatunsitf
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug c++/31131] [4.2/4.3 regression] ICE on invalid constructor definition
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/30303] [4.2/4.3 regression] ICE with invalid constructor definition
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
