[Bug rtl-optimization/28386] [4.1 regression] Wrong code with if condition in loop
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-05 07:06 --- Subject: Bug 28386 Author: ebotcazou Date: Tue Sep 5 07:06:46 2006 New Revision: 116693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116693 Log: PR rtl-optimization/28386 * loop.c (biased_biv_may_wrap_p): Rename to biv_may_wrap_p and remove 'bias' parameter. (maybe_eliminate_biv_1): Adjust for above change. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20060905-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28386
[Bug rtl-optimization/28386] [4.1 regression] Wrong code with if condition in loop
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-05 07:08 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28386
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #5 from thomas at reactsoft dot com 2006-09-05 07:10 --- (In reply to comment #4) > Actually it looks like an oversight of what relayout_decl does. The reason is > that relayout_decl was added by the patch to fix "PR c++/16115" and I think > Jason forgot about user specified alignment because he was only dealing with > PARM_DECLs at the time. Is this also supposed to fix the problem I posted in comment #2? I applied that patch to my gcc but it didn't fix the generated code for me. It's just weird because the bug only appears if the code is complex enough. If it's just a rather simple function, the generated code is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #26 from gcc at mirality dot co dot nz 2006-09-05 07:18 --- This is very aggravating, and *NEEDS* to get fixed soon. Even if only for the common duplicate-symbol-on-most-platforms case, that's a significant improvement over what it's doing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug fortran/28916] Build of the head fails on Mac Intel
--- Comment #6 from federico dot carminati at cern dot ch 2006-09-05 08:04 --- Subject: Re: Build of the head fails on Mac Intel Thanks a lot and sorry for losing your time. Best, Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 79480 Mobile: +41 76 487 4843 On 3 Sep 2006, at 07:28, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-03 > 05:28 --- > cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/sources/gcc up -Pd > > The sources on gnu.org are so out of date, it is not funny. > We use svn now, there is a NOTE file about this in the cvs server. > Read: > http://gcc.gnu.org/svn.html > > This was fixed in 4.2.0 already anyways. > Closing as invalid since you are not building the real head but the > head from a > year or so ago. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > -- > -- > Status|UNCONFIRMED |RESOLVED > Resolution||FIXED > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug tree-optimization/28935] [4.2 regression] Segfault in operand_equal_p with -ftree-vectorize -O3
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-09-05 08:34 --- Subject: Bug 28935 Author: rguenth Date: Tue Sep 5 08:34:00 2006 New Revision: 116695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116695 Log: 2006-09-05 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28935 * tree-ssa-ccp.c (fold_stmt_r): Make sure to fold the condition of a COND_EXPR. * gcc.dg/pr28935.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr28935.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28935
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-09-05 08:36 --- Subject: Bug 28905 Author: rguenth Date: Tue Sep 5 08:36:39 2006 New Revision: 116696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116696 Log: 2006-09-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28905 * tree-vrp.c (fix_equivalence_set): Manually implement !value_ranges_intersect_p to also handle symbolic ranges. * gcc.c-torture/compile/pr28905.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr28905.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-09-05 08:39 --- Subject: Bug 28900 Author: rguenth Date: Tue Sep 5 08:39:42 2006 New Revision: 116697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116697 Log: 2006-09-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28900 * tree-if-conv.c (find_phi_replacement_condition): Gimplify compound conditional before creating COND_EXPR condition. * gcc.dg/torture/pr28900.c: New testcase Added: trunk/gcc/testsuite/gcc.dg/torture/pr28900.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug tree-optimization/28900] [4.1 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-09-05 08:40 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.1.1 |4.1.1 Known to work|4.0.3 |4.0.3 4.2.0 Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE |verify_stmts failed (invalid|verify_stmts failed (invalid |operand to unary operator) |operand to unary operator) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-09-05 08:40 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug tree-optimization/28935] [4.2 regression] Segfault in operand_equal_p with -ftree-vectorize -O3
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-09-05 08:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28935
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-09-05 08:42 --- Yes, would have been my fix, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28948] -fprofile-generate/use and C++ anonymous namespaces don't mix
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-09-05 08:56 --- And you can work around with -frandom-seed=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #5 from uros at kss-loka dot si 2006-09-05 09:35 --- The problem here is following: We already have the patterns, that would satisfy combined instruction (*lshrsi3_cmp) in above testcase. However, combiner rejects combined instruction because the register that holds shifted result is unused! The problematic part is in combine.c, around line 2236 (please read the comment, which describes exactly the situation we have here). This part of code is activated only when the register that holds the result of arith operation is keept alive. This is quite strange - even if the result is unused, resulting code will be still smaller as we avoid extra CC setting instruction. The patch bellow (currently under testing, but so far OK) forces generation of combined instruction even if the arithmetic result is unused. Index: combine.c === --- combine.c (revision 116691) +++ combine.c (working copy) @@ -2244,7 +2244,7 @@ needed, and make the PARALLEL by just replacing I2DEST in I3SRC with I2SRC. Later we will make the PARALLEL that contains I2. */ - if (i1 == 0 && added_sets_2 && GET_CODE (PATTERN (i3)) == SET + if (i1 == 0 && GET_CODE (PATTERN (i3)) == SET && GET_CODE (SET_SRC (PATTERN (i3))) == COMPARE && XEXP (SET_SRC (PATTERN (i3)), 1) == const0_rtx && rtx_equal_p (XEXP (SET_SRC (PATTERN (i3)), 0), i2dest)) @@ -2254,6 +2254,13 @@ enum machine_mode compare_mode; #endif + /* To force generation of the combined comparison and arithmetic +operation PARALLEL, pretend that the set in I2 is to be used, +even if it is dead after I2. This results in better generated +code, as only CC setting arithmetic instruction will be +emitted in conditionals. */ + added_sets_2 = 1; + newpat = PATTERN (i3); SUBST (XEXP (SET_SRC (newpat), 0), i2src); Compiling testcase with this patch results in following code: fct: movl 4(%esp), %eax shrl $5, %eax je .L2 jmp fct1 .p2align 4,,7 .L2: jmp fct2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug c++/28895] 'friend' accepts typedef-name.
--- Comment #4 from pluto at agmk dot net 2006-09-05 10:20 --- *** This bug has been marked as a duplicate of 21498 *** -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
[Bug c++/21498] clause 7.1.5.3/2 of the c++ is not enforced
--- Comment #9 from pluto at agmk dot net 2006-09-05 10:20 --- *** Bug 28895 has been marked as a duplicate of this bug. *** -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
[Bug target/27856] With -Os, loading a constant to a register can use another register
--- Comment #3 from etienne_lorrain at yahoo dot fr 2006-09-05 11:32 --- Just for info, does that means we need to wait for YARA to be included, considering http://gcc.gnu.org/ml/gcc/2006-08/msg00164.html it will probably happen after 4.2 ? I am seeing a lot of them, even some pattern like that to clear %eax: xor %edx,%edx ... mov %edx,%eax ... use %eax ... mov 10,%edx Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27856
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #6 from uros at kss-loka dot si 2006-09-05 11:45 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00137.html BTW: This patch eliminates 869 "test" instructions in povray-3.6.1 compile. (And my test raytraced pictures are still correct.) -- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00137.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-09-04 16:50:06 |2006-09-05 11:45:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug tree-optimization/28948] -fprofile-generate/use and C++ anonymous namespaces don't mix
--- Comment #4 from bangerth at math dot tamu dot edu 2006-09-05 11:51 --- Subject: Re: -fprofile-generate/use and C++ anonymous namespaces don't mix > And you can work around with -frandom-seed=0 Nope, since that means that symbols in anonymous namespaces are the same every time you compile a file, you can't compile the file twice with different flags and later link the whole thing together. -frandom-seed=0 is not compatible with C++ semantics of anonymous namespace members. W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
[Bug c/28954] New: Get unexpected segment error
I define a struct array called 'l' in above the main file. Then I passed 'l' to
load_data(struct line l[]) which is defined in another file called load.c. I
declare load_data(struct line l[]) in load.h.
Then when load_data() want to initialize the l array, a segmentation is
generated.(I have checked that the array is large enough, and I initialized
some elements in l, and printf them out, the value is what I did. But
segmentation error came up as long as I modify the array l).
Then if I renamed l as ll in main file above. Everything worked well then. Or
if I use externs, every thing worked well as well.
main.c
#include
#include
#include"./type.h"
#include"./load.h"
struct line ll[LMAX];
struct machine m[MMAX];
int
main()
{
//int i;
printf("Loading data ...");
fflush(stdout);
ll[0].co[0]=54321;
if(-1==load_data(ll))
{
printf("Missing data. Exiting program.\n");
return 0;
}
printf(" [OK] \n");
return 0;
}
load_data.c
#include"./type.h"
#include
#include
extern struct machine m[MMAX];
//extern struct linel[LMAX];
struct line *l;
FILE *
file_open(const char name[])
{
FILE *f=fopen(name,"r");
if(unlikely(NULL==f))
{
f=fopen(name,"a+");
fclose(f);
return NULL;
}
return f;
}
int
load_equation()
{
int i,j;
FILE *f=file_open("equation");
printf("before critical ");
printf("before critical %lf\n",l[0].co[0]);
l[0].co[0]=;
printf("critical\n");
if(NULL==f)
return -1;
// printf("before loop\n");
for(j=0;j>>0 %p %p %lf\n",l,m,l[0].co[0]);
l[0].co[0]=12345;
printf("after\n");
if(load_equation())
re=-1;
if(load_line_limit())
re=-1;
if(load_seg_prise())
re=-1;
if(load_seg_len())
re=-1;
if(load_speed())
re=-1;
return re;
}
type.h
#ifndef TYPE
#define MMAX 8
#define LMAX 6
#define SEGMAX 10
struct line{
double co[MMAX];
double normal;
double high;
};
struct machine{
double seg_prise[SEGMAX];
double seg[SEGMAX];
double speed;//climb speed, mw per minute
};
struct solution{
double m_power[MMAX];
};
#endif
--
Summary: Get unexpected segment error
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lionghostshop at yahoo dot com dot cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28954
[Bug c/28954] Get unexpected segment error
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-05 12:02 --- foo bar[n] is not the same as foo *bar; -- 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=28954
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-09-05 12:41 --- (In reply to comment #4) > Anyways I am going to test the obvious fix unless you (Ulrich) want to do it. Please go ahead, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-09-05 12:47 --- (In reply to comment #5) > Is this also supposed to fix the problem I posted in comment #2? I applied > that > patch to my gcc but it didn't fix the generated code for me. It's just weird > because the bug only appears if the code is complex enough. If it's just a > rather simple function, the generated code is correct. No, your problem is certainly something completely different. In fact I've never seen GCC (common code) do anything even remotely like: >GCC reserves an area big enough to hold the structure plus padding, >so it can align the structure dynamically at runtime. It stores a >pointer to the reserved area and a pointer to the structure within >the area. Normally, attribute ((aligned)) does not cause any code to be generated that attempts to dynamically adjust alignment at runtime, it simply allows a variable to be aligned up to whatever default stack frame alignment the platform ABI provides for. It appears that the i386 back-end has some special code related to the -mstackrealign option that may be involved here. In any case, this would be something for an i386 back-end person to look into. Since this is a completely unrelated problem, I recommend you open a separate bugzilla for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #7 from uros at kss-loka dot si 2006-09-05 13:43 ---
Hm, proposed patch now generates worse code for following test:
extern int fnc1(void);
extern int fnc2(void);
int test(int x)
{
if (x & 0x02)
return fnc1();
else if (x & 0x01)
return fnc2();
else
return 0;
}
It generates:
test:
movl 4(%esp), %edx
movl %edx, %eax
andl $2, %eax
jne .L10
andl $1, %edx
jne .L11
xorl %eax, %eax
ret
.p2align 4,,7
.L11:
.p2align 4,,8
jmp fnc2
.p2align 4,,7
.L10:
.p2align 4,,7
jmp fnc1
due to marking %eax live in first comparison, "and" is used instead of "test",
and a regmove is emitted before comparison. Ideally gcc should generate:
test:
movl 4(%esp), %eax
testl $2, %eax
jne .L6
andl $1, %eax
jne .L7
xorl %eax, %eax
ret
.p2align 2,,3
.L7:
jmp fnc2
.p2align 2,,3
.L6:
jmp fnc1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug fortran/25091] Results do not conform at different entries
--- Comment #2 from patchapp at dberlin dot org 2006-09-05 14:15 --- Subject: Bug number PR25091 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00145.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25091
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #31 from pluto at agmk dot net 2006-09-05 14:31 --- is it possible to make gcc unwinder work for solaris too? at this moment unwinding (after throwing the std::exception from signal handler) on sunos-5.9 looks like this: 0x1141c : signalHandler(int)+0x8 0x7e8a7b50 : _setuid+0x4c from /usr/lib/sparcv9/libc.so.1 terminate called after throwing an instance of 'std::runtime_error' what(): test Abort (core dumped) -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug c/28955] New: "unrecognizable insn" : atomic op on short with bit inversion on val
I am reporting compiler problem as advised by error message.
GCC version: 4.1.0
System type: build machine is P4 3GHz, building for target i586
# Code to reproduce problem
###
short test(short y)
{
return __sync_and_and_fetch(&y, ~(0x01| 0x02 | 0x03))
}
Note: If the code is changed so that no bit-wise inversion is done, no problem.
# Compilation error message
###
test.c:nnn: error: unrecognizable insn:
(insn 11 16 12 2 (set:HI 66)
(const_int 65532 [0xfffc])) -1 (nil)
(nil))
test.c:nnn: internal compiler error: in extract_insn, at recog.c:2084
## MAKEFILE extract on optimization settings :
ifeq ($(strip $(bldOPTIMIZE)),1)
OPTIMIZE:= \
-fdefer-pop -fthread-jumps -fregmove -foptimize-sibling-calls \
-fcaller-saves -finline-functions \
-fexpensive-optimizations -fstrength-reduce \
-frerun-cse-after-loop -frerun-loop-opt \
-fgcse -fgcse-lm -fgcse-sm -fcse-follow-jumps -fcse-skip-blocks
\
-fschedule-insns -fschedule-insns2 -fsched-spec-load \
-fomit-frame-pointer -fmerge-constants -fforce-addr \
-foptimize-register-move
ifeq ($(GCC4),1)
OPTIMIZE+=\
-fgcse-las -fgcse-after-reload
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-ftree-pre \
-ftree-ccp -ftree-dce -ftree-dominator-opts -ftree-ch
-ftree-loop-optimize \
-ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts
-ftree-sra \
-ftree-copyrename -ftree-ter -ftree-lrs -ftree-vectorize \
-ftree-fre
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-freorder-blocks -freorder-blocks-and-partition
-freorder-functions
endif
ifeq ($(GCC$),1)
OPTIMIZE+=\
-fweb -funroll-loops -funroll-all-loops -fsplit-ivs-in-unroller
\
-fvariable-expansion-in-unroller
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-fmove-loop-invariants \
-ftracer -fsched2-use-traces \
-fsched2-use-superblocks
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-fsched-spec-load
# -fsched-spec-load-dangerous
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-freschedule-modulo-scheduled-loops \
-fif-conversion -fif-conversion2 \
-fdelete-null-pointer-checks
endif
ifeq ($(GCC4),1)
OPTIMIZE+=\
-floop-optimize -floop-optimize2 -fcrossjumping
endif
--
Summary: "unrecognizable insn" : atomic op on short with bit
inversion on val
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kawika at QEDmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28955
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #8 from hjl at lucon dot org 2006-09-05 14:54 --- TARGET_PARTIAL_FLAG_REG_STALL and TARGET_USE_INCDEC are totally different. TARGET_USE_INCDEC favors inc/dec over add/sub while TARGET_PARTIAL_FLAG_REG_STALL adds test after shift. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug target/28955] "unrecognizable insn" : atomic op on short with bit inversion on val
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-05 15:09 ---
Confirmed. In short:
short test(short y)
{
return __sync_and_and_fetch(&y, ~(0x01| 0x02 | 0x03));
}
ICEs with -O -march=pentium4:
t.c: In function 'test':
t.c:4: error: unrecognizable insn:
(insn 14 19 15 2 (set (reg:HI 64)
(const_int 65532 [0xfffc])) -1 (nil)
(nil))
t.c:4: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.
with -march=i386 we promote this to HI mode.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |target
Ever Confirmed|0 |1
GCC target triplet||i?86-*-*
Last reconfirmed|-00-00 00:00:00 |2006-09-05 15:09:15
date||
Summary|"unrecognizable insn" : |"unrecognizable insn" :
|atomic op on short with bit |atomic op on short with bit
|inversion on val|inversion on val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28955
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-05 15:41 --- *** Bug 28955 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kawika at QEDmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug target/28955] "unrecognizable insn" : atomic op on short with bit inversion on val
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-05 15:41 --- *** This bug has been marked as a duplicate of 28924 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28955
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #2 from janis at gcc dot gnu dot org 2006-09-05 16:31 --- David is pursuing this as part of a larger effort to fix licenses for GCC libraries. David, any news? -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #3 from dpatel at apple dot com 2006-09-05 16:44 --- I know this is a bootstrap failure, however is there a small reproducible test case for this crash ? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-05 16:58 --- (In reply to comment #3) > I know this is a bootstrap failure, however is there a small reproducible > test > case for this crash ? Thanks. THe problem in comment #1 has already been fixed for a while now. See the bugs that this bug depends on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #5 from dpatel at apple dot com 2006-09-05 17:01 --- I'd already verified that. How about "-O3 -ftree-vectorize" bootstrap failure ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
--- Comment #4 from bonzini at gnu dot org 2006-09-05 17:41 --- Subject: Bug 26847 Author: bonzini Date: Tue Sep 5 17:41:22 2006 New Revision: 116701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116701 Log: 2006-09-05 Paolo Bonzini <[EMAIL PROTECTED]> PR rtl-optimization/26847 * simplify-rtx.c (struct simplify_plus_minus_op_data): Remove ix. (simplify_plus_minus_op_data_cmp): For REGs, break ties on the regno. (simplify_plus_minus): Count n_constants while filling ops. Replace qsort with insertion sort. Before going through the array to simplify pairs, sort it. Delay early exit until after the first sort, exiting only if no swaps occurred. Simplify pairs in reversed order, without special-casing the first iteration. Pack ops after simplifying pairs. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #5 from bergner at vnet dot ibm dot com 2006-09-05 18:43 --- Created an attachment (id=12190) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12190&action=view) Patch to rs6000_legitimize_address to force base pointers into rA position of indexed load/store instructions. Ok, taking Paolo's suggestion of moving the change into rs6000_legititmize_address, I'm trying the attached patch which bootstraps fine and fixes the base pointer order for us. I'm running the testsuite now and will report back when it's done. * config/rs6000/rs6000.c (rs6000_legitimize_address): For performance reasons, force PLUS register operands that are base pointers to be the first operand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #6 from bonzini at gnu dot org 2006-09-05 19:25 --- To clarify, I make this suggestion because I think that we were getting it right pre-4.2 just out of luck. I also thought about having a lower commutative_operand_precedence for REG_POINTER regs than normal regs, but in fact regs need to have the same precedence as other rtx's of class RTX_OBJ, or you get pessimization on x86 (e.g. on crafty). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #10 from pault at gcc dot gnu dot org 2006-09-05 19:38 --- (In reply to comment #9) > The proposed change in comment #8 appears to give several testsuite failures. > Yes, I know; see the email that I sent you today. The original patch on #5 works fine and is nearly the right solution. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug fortran/20779] ALLOCATEing the STAT variable not detected
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-05 19:39 --- A patch is ready but I have not had time to post it. Watch the list this weekend. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-31 20:17:24 |2006-09-05 19:39:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20779
[Bug fortran/20891] allocation depends on other object in same allocation
--- Comment #2 from pault at gcc dot gnu dot org 2006-09-05 19:40 --- A patch is ready but I have not had time to post it. Watch the list this weekend. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-31 20:00:24 |2006-09-05 19:40:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20891
[Bug fortran/28890] ICE on write
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-05 19:40 --- A patch is ready but I have not had time to post it. Watch the list this weekend. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-29 21:26:24 |2006-09-05 19:40:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28890
[Bug fortran/28923] Bad triplet interpretation in initialization
--- Comment #1 from pault at gcc dot gnu dot org 2006-09-05 19:41 --- I had better deal with this, since I am teh author of the wrong bit of logic. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-05 19:41:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923
[Bug fortran/25091] Results do not conform at different entries
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-05 19:42 --- The patch is mine! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-20 21:51:14 |2006-09-05 19:42:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25091
[Bug fortran/25092] Result lengths different at different entries
--- Comment #2 from pault at gcc dot gnu dot org 2006-09-05 19:43 --- The patch is mine! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-20 21:51:58 |2006-09-05 19:43:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25092
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #7 from bergner at vnet dot ibm dot com 2006-09-05 20:01 --- Well, to get REG_POINTER regs to be the first operand, we'd need to increase their commutative_operand_precedence. I tried that change already, but that led to an infinite recursion loop while attempting to simplify the rtl. As you said, the current ordering seems to be relied upon by the code for simplifications. My rs6000_legitimize_address change is still running through the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/28956] New: Illegal array initialization accepted
Consider:
struct Foo {
Foo(); // comment out -> g++ fails with "error: invalid initializer"
};
void fn()
{
Foo f[2];
Foo g[2] = f;
}
The test above is accepted by g++ (tried 3.4.6, 4.0.0, 4.1.1 and 4.2-20060902).
EDG fails with:
$ edgcpfe pp.cpp
"pp.cpp", line 8: error: initialization with "{...}" expected for aggregate
object
Foo g[2] = f;
^
1 error detected in the compilation of "pp.cpp".
Here is the original test case (also accepted by all versions of g++):
template
struct pair {
pair(const T& t, const U& u) : first(t), second(u) { }
T first;
U second;
};
struct Foo {
Foo(); // comment out -> g++ fails with
// "error: ISO C++ forbids assignment of arrays"
};
int main()
{
Foo f[2];
pair p (1, f);
return 0;
}
And analysis of it by William M. (Mike) Miller | Edison Design Group, Inc.:
> Could you please confirm that this is a g++ bug?
Yes, it's a bug. The Standard (12.6.2 paragraph 3) defines an initialization
like "second(u)" to be direct-initialization as described in section 8.5.
Section 8.5 paragraph 14 says that initialization of an array object is handled
in section 8.5.1. However, 8.5.1 does not provide for any way of initializing
an array from another array (except for the special case of a string literal,
8.5.2). Arrays can only be initialized to a value using the brace notation,
which is not permitted in a mem-initializer.
--
Summary: Illegal array initialization accepted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28956
[Bug c++/28956] Illegal array initialization accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-05 20:42 --- There are two different bugs here, the first one is a regression from 3.2.3. The second one is accepted by all versions of GCC I have access to from 2.95.3 and upwards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28956
[Bug other/28957] New: unoptimal virtual method call.
struct A
{
typedef void ( A::* pmf )();
virtual ~A();
virtual void foo() = 0;
};
void unoptimized_loop( A* a, A::pmf f )
{
while ( 1 )
( a->*f )();
}
void optimized_loop( A* a, A::pmf f )
{
typedef void (* pf)( A* );
pf __f = (pf)( a->*f );
while ( 1 )
__f( a );
}
both loops do the same thing with different speed impact.
$ g++ pmf_opt.cpp -Wall -c -O2 -Wno-pmf-conversions --save-temps -fverbose-asm
_Z16unoptimized_loopP1AMS_FvvE:
pushq %r12#
movq%rsi, %r12 # f, tmp68
andl$1, %r12d #, tmp68
pushq %rbp#
leaq(%rdi,%rdx), %rbp #, tmp70
pushq %rbx#
movq%rsi, %rbx # f, f
subq$16, %rsp #,
movq%rsi, (%rsp)# f, f
movq%rdx, 8(%rsp) # f, f
.L3:testq %r12, %r12 # tmp68
movq%rbx, %rax # f, f$__pfn
je .L6 #,
movq(%rbp), %rax#, tmp69
movq-1(%rax,%rbx), %rax #, f$__pfn
.L6:movq%rbp, %rdi # tmp70, prephitmp.36
call*%rax # f$__pfn
jmp .L3
_Z14optimized_loopP1AMS_FvvE:
pushq %rbp#
movq%rdi, %rbp # a, a
pushq %rbx#
movq%rsi, %rbx # f, f$__pfn
subq$24, %rsp #,
testb $1, %sil#, f$__pfn
movq%rsi, 8(%rsp) # f, f
movq%rdx, 16(%rsp) # f, f
je .L14#,
movq(%rdi,%rdx), %rax #* f, tmp68
movq-1(%rax,%rsi), %rbx #, f$__pfn
.L14: movq%rbp, %rdi # a, a
call*%rbx # f$__pfn
jmp .L14
--
Summary: unoptimal virtual method call.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28957
[Bug other/28957] unoptimal virtual method call.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-05 21:08 --- -funswitch-loops fixes the loops. For the first function, we get: .L4: movl%ebx, (%esp) call*%esi jmp .L4 and: .L3: movl(%ebx), %eax movl%ebx, (%esp) call*-1(%eax,%edi) .p2align 4,,4 jmp .L3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28957
[Bug other/28957] unoptimal virtual method call.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-05 21:11 --- So this is either fixed with -funswitch-loops and/or -O3 which enables -funswitch-loops. And this has been fixed since 3.4.0 which added -funswitch-loops. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28957
[Bug other/28957] unoptimal virtual method call.
--- Comment #3 from pluto at agmk dot net 2006-09-05 21:35 --- (In reply to comment #1) > -funswitch-loops fixes the loops. i don't think it is fixed. imho this is only a partial fix. > For the first function, we get: > .L4: > movl%ebx, (%esp) > call*%esi > jmp .L4 > > and: > .L3: > movl(%ebx), %eax<=== [1] > movl%ebx, (%esp) > call*-1(%eax,%edi) <=== [1] > .p2align 4,,4 > jmp .L3 [1] is still less effective than optimized_loop. movl12(%ebp), %eax # f, f movl8(%ebp), %esi # a, a movl16(%ebp), %edx # f, f testb $1, %al #, f$__pfn movl%eax, %ebx # f, f$__pfn je .L13 movl(%esi,%edx), %eax #* f$__delta, tmp65 movl-1(%eax,%ebx), %ebx #, f$__pfn .L13: movl%esi, (%esp)# a, call*%ebx # f$__pfn jmp .L13 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28957
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
--- Comment #5 from bonzini at gnu dot org 2006-09-05 21:40 --- patch committed, confirmed fixed by andreas -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #16 from kkojima at gcc dot gnu dot org 2006-09-05 21:41 --- Subject: Bug 28764 Author: kkojima Date: Tue Sep 5 21:41:23 2006 New Revision: 116703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116703 Log: PR target/28764 * mode-switching.c (optimize_mode_switching): Make the destination block of an abnormal edge have no anticipatable mode. Don't insert mode switching code at the end of the source block of an abnormal edge. Modified: trunk/gcc/ChangeLog trunk/gcc/mode-switching.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug target/28904] operand out of range on Linux/PowerPC
--- Comment #3 from amodra at bigpond dot net dot au 2006-09-05 22:50 --- This is a limitation of the -fPIC implementation used on powerpc-linux. You get a maximum of 64K bytes of GOT entries per function (ie. 16K entries). -fpic is even more limited, with only 64K bytes of GOT for the entire executable. (-fpic used to be 32k for the entire executable until the linker was enhanced.) -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-05 22:50:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
[Bug c++/28513] [4.0/4.1/4.2 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
--- Comment #2 from jason at gcc dot gnu dot org 2006-09-05 23:14 --- I guess this warning was never implemented in the new parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug c++/19809] [4.0/4.1/4.2 Regression] Multiple definitions of friend functions in template classes
--- Comment #8 from jason at gcc dot gnu dot org 2006-09-05 23:26 --- I'm not sure this is actually a bug. -- 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|NEW |ASSIGNED Last reconfirmed|2006-08-28 05:31:36 |2006-09-05 23:26:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/19809] [4.0/4.1/4.2 Regression] Multiple definitions of friend functions in template classes
--- Comment #9 from jason at gcc dot gnu dot org 2006-09-05 23:27 --- Actually, I am, didn't mean to add that comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/26102] [4.1/4.2 regression] "using Base::member" nonsense
-- 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|NEW |ASSIGNED Last reconfirmed|2006-02-05 14:50:35 |2006-09-05 23:54:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26102
[Bug c++/26571] [4.0/4.1/4.2 regression] Bad diagnostic using type modifier with struct
-- 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|NEW |ASSIGNED Last reconfirmed|2006-08-27 21:28:20 |2006-09-06 00:12:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26571
[Bug c/28958] New: Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
(This was originally reported in Ubuntu, at https://launchpad.net/distros/ubuntu/+source/vpnc/+bug/53341) Compiling vpnc with any optimisations with GCC 4.1 causes a failure to connect to a VPN. The issue is in the setup_link function, in vpnc.c, although I've got no idea exactly what the problem with that function is. -- Summary: Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot grant at ubuntu dot com dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug c/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-06 00:20 --- And this is not enough information to reproduce this bug, Can you attach a testcase? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug c++/26671] [4.0/4.1/4.2 Regression] Missing "warning: reference to local variable returned"
-- 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|NEW |ASSIGNED Last reconfirmed|2006-03-14 00:10:44 |2006-09-06 00:23:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26671
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #2 from william dot grant at ubuntu dot com dot au 2006-09-06 00:45 --- Created an attachment (id=12191) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12191&action=view) Working vpnc binary, compiled with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #3 from william dot grant at ubuntu dot com dot au 2006-09-06 00:47 --- Created an attachment (id=12192) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12192&action=view) A broken vpnc binary compiled with -O3, it doesn't connect properly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug c++/26696] [4.0/4.1/4.2 Regression] ICE with statement forming unused static member function reference
-- 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|NEW |ASSIGNED Last reconfirmed|2006-05-21 20:56:11 |2006-09-06 00:48:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #4 from william dot grant at ubuntu dot com dot au 2006-09-06 00:51 --- Created an attachment (id=12193) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12193&action=view) Another broken vpnc binary, this time compiled with -O1, still doesn't connect properly/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #5 from william dot grant at ubuntu dot com dot au 2006-09-06 00:54 --- Created an attachment (id=12194) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12194&action=view) The offending source file, setup_link is the function with issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 00:57 --- us->u.id.length = 4; us->u.id.data = xallocc(4); memcpy(us->u.id.data, s->our_address, sizeof(struct in_addr)); That looks wrong as sizeof(struct in_addr) does not have to equal 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug c++/19809] [4.0/4.1/4.2 Regression] Multiple definitions of friend functions in template classes
--- Comment #10 from jason at gcc dot gnu dot org 2006-09-06 01:15 --- Subject: Bug 19809 Author: jason Date: Wed Sep 6 01:15:09 2006 New Revision: 116709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116709 Log: PR c++/26102 * name-lookup.c (do_class_using_decl): Try to find the base even if bases_dependent_p. * pt.c (type_dependent_expression_p): A USING_DECL is dependent. PR c++/19809 * pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl. Added: trunk/gcc/testsuite/g++.dg/template/friend47.C trunk/gcc/testsuite/g++.dg/template/using14.C Modified: trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/26102] [4.1/4.2 regression] "using Base::member" nonsense
--- Comment #7 from jason at gcc dot gnu dot org 2006-09-06 01:15 --- Subject: Bug 26102 Author: jason Date: Wed Sep 6 01:15:09 2006 New Revision: 116709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116709 Log: PR c++/26102 * name-lookup.c (do_class_using_decl): Try to find the base even if bases_dependent_p. * pt.c (type_dependent_expression_p): A USING_DECL is dependent. PR c++/19809 * pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl. Added: trunk/gcc/testsuite/g++.dg/template/friend47.C trunk/gcc/testsuite/g++.dg/template/using14.C Modified: trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26102
[Bug c++/19809] [4.0/4.1/4.2 Regression] Multiple definitions of friend functions in template classes
--- Comment #11 from jason at gcc dot gnu dot org 2006-09-06 01:15 --- Subject: Bug 19809 Author: jason Date: Wed Sep 6 01:15:39 2006 New Revision: 116710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116710 Log: PR c++/26102 * name-lookup.c (do_class_using_decl): Try to find the base even if bases_dependent_p. * pt.c (type_dependent_expression_p): A USING_DECL is dependent. PR c++/19809 * pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl. Modified: trunk/gcc/cp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/26102] [4.1/4.2 regression] "using Base::member" nonsense
--- Comment #8 from jason at gcc dot gnu dot org 2006-09-06 01:15 --- Subject: Bug 26102 Author: jason Date: Wed Sep 6 01:15:39 2006 New Revision: 116710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116710 Log: PR c++/26102 * name-lookup.c (do_class_using_decl): Try to find the base even if bases_dependent_p. * pt.c (type_dependent_expression_p): A USING_DECL is dependent. PR c++/19809 * pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl. Modified: trunk/gcc/cp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26102
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #7 from william dot grant at ubuntu dot com dot au 2006-09-06 01:25 --- Could this cause the bug if optimisations are enabled? I don't know anything about the vpnc source, I just uploaded the last two Ubuntu revisions. -- william dot grant at ubuntu dot com dot au changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6
--- Comment #11 from craigwd2000 at gmail dot com 2006-09-06 02:43 --- I just tried building GCC 4.1.1 with the following options: I ran ../configure --enable-threads --x-includes=/usr/X11R6 --x-libraries=/usr/X11R6 --with-mpfr=/usr/local/lib --with-gmp=/usr/local/lib from ~/Desktop/Downloads/GCC/gcc-4.1.1/gcc/objdir. I ran make bootstrap & got the following errors: make[1]: *** No rule to make target `dummy-checksum.c', needed by `dummy-checksum.o'. Stop. make: *** [stage1_build] Error 2. I'm still using GCC 4.0.1 for compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 04:54 --- (In reply to comment #7) > Could this cause the bug if optimisations are enabled? I don't know anything > about the vpnc source, I just uploaded the last two Ubuntu revisions. It could as the memory layout will be different, why don't you try to use sizeof(struct in_addr) instead of 4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug c++/26671] [4.0/4.1/4.2 Regression] Missing "warning: reference to local variable returned"
--- Comment #4 from jason at gcc dot gnu dot org 2006-09-06 05:25 --- Subject: Bug 26671 Author: jason Date: Wed Sep 6 05:25:29 2006 New Revision: 116714 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116714 Log: PR c++/26671 * typeck.c (maybe_warn_about_returning_address_of_local): Look through COMPONENT_REF and ARRAY_REF. Added: trunk/gcc/testsuite/g++.dg/warn/return-reference2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26671
[Bug c++/26571] [4.0/4.1/4.2 regression] Bad diagnostic using type modifier with struct
--- Comment #3 from jason at gcc dot gnu dot org 2006-09-06 05:28 --- Subject: Bug 26571 Author: jason Date: Wed Sep 6 05:28:08 2006 New Revision: 116715 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116715 Log: PR c++/26571 * parser.c (cp_parser_diagnose_invalid_type_name): Handle the case where the name is a type used incorrectly. Added: trunk/gcc/testsuite/g++.dg/parse/typespec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26571
[Bug c++/27371] [4.1/4.2 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))
-- 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|NEW |ASSIGNED Last reconfirmed|2006-05-04 14:47:45 |2006-09-06 05:49:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
[Bug c++/27371] [4.1/4.2 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))
--- Comment #3 from jason at gcc dot gnu dot org 2006-09-06 05:59 --- This worked in 4.0 by accident, because of the NRV implementation I had in that release which pushed aggregate return values into the argument list of a call. This had some problems, so I later changed it to use a MODIFY_EXPR, which properly expresses what's going on, but interferes with this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 06:07 --- Subject: Bug 28952 Author: pinskia Date: Wed Sep 6 06:06:55 2006 New Revision: 116716 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116716 Log: 2006-09-05 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/28952 * tree-vect-transform.c (vectorizable_condition): Move the check for the type after the check for simple condition. 2006-09-05 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/28952 * gcc.dg/vect/pr28952.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr28952.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28952] [4.1 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-06 06:08 --- Fixed on the mainline, this is a latent bug on the 4.1 branch which was not there in 4.0 so I will also apply it to the 4.1 branch after a week or so. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 regression] tree check:|[4.1 regression] tree check: |expected class 'expression',|expected class 'expression', |have 'exceptional' |have 'exceptional' |(ssa_name) in |(ssa_name) in |vectorizable_condition, at |vectorizable_condition, at |tree-vect-transform.c:2122 |tree-vect-transform.c:2122 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:13 --- Subject: Bug 28937 Author: pinskia Date: Wed Sep 6 06:13:22 2006 New Revision: 116717 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116717 Log: 2006-09-05 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/28937 * tree-flow.h (tree_ssa_unswitch_loops): Return unsigned int. (canonicalize_induction_variables): Likewise. (tree_unroll_loops_completely): Likewise. (tree_ssa_prefetch_arrays): Likewise. (remove_empty_loops): Likewise. * tree-ssa-loop-unswitch.c (tree_ssa_unswitch_loops): Return TODO_cleanup_cfg instead of directly calling cleanup_tree_cfg_loop. * tree-ssa-loop-ivcanon.c (canonicalize_induction_variables): Likewise. (tree_unroll_loops_completely): Likewise. (remove_empty_loops): Likewise. * tree-ssa-loop-prefetch.c (tree_ssa_prefetch_arrays): Likewise. * tree-ssa-loop.c (tree_ssa_loop_unswitch): Use the return value of tree_ssa_unswitch_loops. (tree_ssa_loop_ivcanon): Use the return value of canonicalize_induction_variables. (tree_ssa_empty_loop): Use the return value of remove_empty_loops. (tree_complete_unroll): Use the return value of tree_unroll_loops_completely. (tree_ssa_loop_prefetch): Use the return value of tree_ssa_prefetch_arrays. * passes.c (execute_todo): Before Cleanup CFG, set updating_used_alone and after cleanup CFG, call recalculate_used_alone. 2006-09-05 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/28937 * g++.dg/opt/unroll2.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/unroll2.C Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-loop-ivcanon.c trunk/gcc/tree-ssa-loop-prefetch.c trunk/gcc/tree-ssa-loop-unswitch.c trunk/gcc/tree-ssa-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-06 06:14 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-06 06:14 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-06 06:30 ---
And here is a testcase which is reproducible without the vectorizer:
int t[4];
__attribute__((vector_size(16))) int f(void)
{
__attribute__((vector_size(16))) int t1 = {(int)&t[0], (int)&t[1], (int)&t[2],
(int)&t[3]};
return t1;
}
That testcase above shows more problems than I actually want to touch right
now.
Here was my fix for the x86 crash (but it does not fix the powerpc-linux with
-maltivec crash):
Index: tree.c
===
--- tree.c (revision 116689)
+++ tree.c (working copy)
@@ -969,9 +969,11 @@ build_vector (tree type, tree vals)
for (link = vals; link; link = TREE_CHAIN (link))
{
tree value = TREE_VALUE (link);
-
- over1 |= TREE_OVERFLOW (value);
- over2 |= TREE_CONSTANT_OVERFLOW (value);
+ if (CONSTANT_CLASS_P (value))
+ {
+ over1 |= TREE_OVERFLOW (value);
+ over2 |= TREE_CONSTANT_OVERFLOW (value);
+ }
}
TREE_OVERFLOW (v) = over1;
Index: expmed.c
===
--- expmed.c(revision 116689)
+++ expmed.c(working copy)
@@ -4945,6 +4945,9 @@ make_tree (tree type, rtx x)
switch (GET_CODE (x))
{
+case CONST:
+ return make_tree (type, XEXP (x, 0));
+
case CONST_INT:
{
HOST_WIDE_INT hi = 0;
@@ -4979,6 +4982,7 @@ make_tree (tree type, rtx x)
int i, units;
rtx elt;
tree t = NULL_TREE;
+ tree type1 = TREE_TYPE (type);
units = CONST_VECTOR_NUNITS (x);
@@ -4986,7 +4990,7 @@ make_tree (tree type, rtx x)
for (i = units - 1; i >= 0; --i)
{
elt = CONST_VECTOR_ELT (x, i);
- t = tree_cons (NULL_TREE, make_tree (type, elt), t);
+ t = tree_cons (NULL_TREE, make_tree (type1, elt), t);
}
return build_vector (type, t);
@@ -5044,6 +5048,14 @@ make_tree (tree type, rtx x)
GET_CODE (x) == ZERO_EXTEND);
return fold_convert (type, make_tree (t, XEXP (x, 0)));
+case SYMBOL_REF:
+ if (SYMBOL_REF_DECL (x))
+ {
+ tree pointer;
+ t = SYMBOL_REF_DECL (x);
+ pointer = build_pointer_type (TREE_TYPE (t));
+ return fold_convert (type, fold_build1 (ADDR_EXPR, pointer, t));
+ }
default:
t = build_decl (VAR_DECL, NULL_TREE, type);
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:33 --- Note I think the PPC-linux-gnu crash is actually caused by: 2006-06-20 Roger Sayle <[EMAIL PROTECTED]> * expr.c (expand_expr_real_1) : For vector constants with integer modes, attempt to directly construct an integer constant. But I have not checked but the backtrace is: (gdb) #8 0x085cda79 in copy_constant (exp=0xb7d40cd8) at ../../gcc/varasm.c:2742 2742ce->value = copy_constant (value); (gdb) #9 0x085ce18b in build_constant_desc (exp=0xb7d40cd8) at ../../gcc/varasm.c:2815 2815 desc->value = copy_constant (exp); (gdb) #10 0x085ce4be in output_constant_def (exp=0xb7d40cd8, defer=1) at ../../gcc/varasm.c:2885 2885 desc = build_constant_desc (exp); (gdb) #11 0x0834d3f4 in expand_expr_constant (exp=0xb7d40cd8, defer=1, modifier=EXPAND_NORMAL) at ../../gcc/expr.c:6433 6433 mem = output_constant_def (exp, defer); (gdb) up #12 0x0835084f in expand_expr_real_1 (exp=0xb7d40cd8, target=0xb7d2b954, tmode=V4SImode, modifier=EXPAND_NORMAL, alt_rtl=0xbf977bf8) at ../../gcc/expr.c:7119 7119 rtx constructor = expand_expr_constant (exp, 1, modifier); (gdb) #13 0x0834df9d in expand_expr_real (exp=0xb7d40cd8, target=0xb7d2b954, tmode=V4SImode, modifier=EXPAND_NORMAL, alt_rtl=0xbf977bf8) at ../../gcc/expr.c:6706 6706 ret = expand_expr_real_1 (exp, target, tmode, modifier, alt_rtl); (gdb) #14 0x08340493 in store_expr (exp=0xb7d40cd8, target=0xb7d2b954, call_param_p=0) at ../../gcc/expr.c:4370 4370 temp = expand_expr_real (exp, target, GET_MODE (target), (gdb) #15 0x0833f7dc in expand_assignment (to=0xb7d37660, from=0xb7d40cd8) at ../../gcc/expr.c:4249 4249 result = store_expr (from, to_rtx, 0); (gdb) And then we go into an infinite loop calling copy_constant on a decl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org GCC target triplet|x86-64-linux| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 06:36 --- (In reply to comment #2) This problem is recorded in a different place, we ignore bigger alignment for stack variables currently. I don't have the number off hand either but I know it has been filed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #9 from thomas at reactsoft dot com 2006-09-06 06:46 --- (In reply to comment #8) > (In reply to comment #2) > This problem is recorded in a different place, we ignore bigger alignment for > stack variables currently. I don't have the number off hand either but I know > it has been filed. Thanks. Before I posted the problem I already looked for the bug, this report came very close (I believed) to what the problem could be. I'll see if I can find the correct bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
