[Bug libstdc++/15910] can't compile self defined void distance(std::vectorT, std::vectorT)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-11 06:31 --- Subject: Re: can't compile self defined void distance(std::vectorT, std::vectorT) adah at netstd dot com [EMAIL PROTECTED] writes: | Furthermore, and more importantly, GCC bugzilla is the not the place | to record UNEXPECTED or PROBLEM with the C++ standard. | | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is | never considered a PRoblem at all? Ahem. Can you read? | If it is, please show me where I can read it. I'm very willing to do so if you provide evidence that you can read. | should be output. If this function is in some namespace and the original | function call is not qualified, then an additional warning on argument- | dependent lookup should be emitted. | | Simple rules. I do not think it is magic. Surely, your rules do not require magic. They just appear nonsensical to me. As argument dependent name lookup has become an essential part of C++ libraries, begining the standard one. | No. If I put it simply, then this behaviour violates the rationale of | namespaces. Which rationale? | This is not the behaviour I am currently requesting. I just wanted to told | Wolfgang there is a third way to `fix' the problem which I prefer better than | his suggestions. Essentially, you're here just to argue. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vectorT, std::vectorT)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-11 06:46 --- Subject: Re: can't compile self defined void distance(std::vectorT, std::vectorT) adah at netstd dot com [EMAIL PROTECTED] writes: | Hi Gaby, | | I have read Sutter's Modest Proposal on fixing ADL that you referred to me. If | you had told me earlier about this instead of bluntly telling me this was not a | GCC bug, It still is NOT a GCC bug, no matter how you put it. GCC correctly implements the standard specifications. Just because you happen not to like the consequences of the rules under some circumstances does not make it a GCC bug. Furthermore, I've suggested from the very outset that you take the issue to the C++ committee -- which if you have done, you would have discovered the many facets of fixes you are discovering now. That was no bluntly telling you. It is not a GCC bug, it is a fact. You would have learnt more about the subject when you took it to the apporpriate place, is also a fact. But, you were obsessed by the very idea that it must be a GCC bug, rejecting outright suggestions to take the issue to the appropriate places and only afterward half-admitting that is what you would have done and are putting blame on other people for your irrational refusal to give more thoughts to the issue and move and discuss it in the apporpriate forums. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug fortran/23323] New: Internal compiler error with CHARACTER functions and -fdefault-integer-8
When compiling the following subroutine test.F: --- snip SUBROUTINE BUG(ID,PARNAM) IMPLICIT NONE C .. Scalar Arguments .. CHARACTER *8 PARNAM INTEGER ID C .. External Functions .. CHARACTER *8 PANAME EXTERNAL PANAME C PARNAM = PANAME(ID) C RETURN END --- snap using gfortran -v -save-temps -fdefault-integer-8 -c test.F gives an internal compiler error: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.0.1/configure --prefix=/tmp2/denk/GCC4.0.1 --exec-p refix=/tmp2/denk/GCC4.0.1/LINUXAMD64 --enable-languages=c,c++,f95,java --with-gm p=/tmp2/denk/GCC4.0.1/LINUXAMD64 --with-mpfr=/tmp2/denk/GCC4.0.1 Thread model: posix gcc version 4.0.1 /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../libexec/gcc/x86_64-unknown- linux-gnu/4.0.1/cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -iprefix / share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../lib/gcc/x86_64-unknown-linux- gnu/4.0.1/ test.F -mtune=k8 -fdefault-integer-8 -fpch-preprocess -o test.f cc1: warning: command line option -fdefault-integer-8 is valid for F95 but not for C ignoring nonexistent directory /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin /../lib/gcc/x86_64-unknown-linux-gnu/4.0.1/../../../../x86_64-unknown-linux-gnu/ include ignoring duplicate directory /tmp2/denk/GCC4.0.1/LINUXAMD64/lib/gcc/x86_64-unkn own-linux-gnu/4.0.1/include ignoring nonexistent directory /tmp2/denk/GCC4.0.1/LINUXAMD64/lib/gcc/x86_64-un known-linux-gnu/4.0.1/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../lib/gcc/x86_64-unknown-linu x-gnu/4.0.1/include /usr/local/include /tmp2/denk/GCC4.0.1/include /usr/include End of search list. /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../libexec/gcc/x86_64-unknown- linux-gnu/4.0.1/f951 test.f -ffixed-form -quiet -dumpbase test.F -mtune=k8 -auxb ase test -version -fdefault-integer-8 -o test.s GNU F95 version 4.0.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 test.F: In function 'bug': test.F:1: internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr .c:782 Removing the option -fdefault-integer-8 gives a sucessful compile. -- Summary: Internal compiler error with CHARACTER functions and - fdefault-integer-8 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: georg dot denk at infineon dot com CC: gcc-bugs at gcc dot gnu dot org,georg dot denk at infineon dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: Linux kruemel 2.4.21-32.0.1.ELsmp #1 SMP Tue Jun 7 12:33:30 MEST GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23323
[Bug c/23324] New: unsigned bitfield in struct not passed correctly as argument
The following (generated) code fails an assertion that checks that values
passed to a function are
received correctly. This fails for one value:
./gcc-4.1.1-ppc-cpp
gcc-4.1.1-ppc.c:140: failed assertion `yv7.mv7 == dp7.mv7'
Abort trap
The particular value is an unsigned bitfield as part of a struct. The bug is
likely to be related to inlining.
The bug is detected in caller_bf7 but does not occur when the call to
caller_bf6 is removed.
int main( int argc, char **argv )
{
caller_bf6 ();
caller_bf7 ();
return errors;
}
To reproduce the bug compile and run the attached code:
: tmp; /scratch/lindig/bin/gcc -O2 -o gcc-4.1.1-ppc-cpp gcc-4.1.1-ppc-cpp.c
: tmp; ./gcc-4.1.1-ppc-cpp
gcc-4.1.1-ppc.c:140: failed assertion `yv7.mv7 == dp7.mv7'
Abort trap
: tmp; /scratch/lindig/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc/configure --prefix=/scratch/lindig --enable-languages=c
: (reconfigured) ../
gcc/configure --prefix=/scratch/lindig --enable-languages=c : (reconfigured)
../gcc/configure --
prefix=/scratch/lindig --enable-languages=c --no-create --no-recursion
Thread model: posix
gcc version 4.1.0 20050810 (experimental)
The code was generated by my test-code generator Quest:
http://www.st.cs.uni-sb.de/~lindig/src/quest/index.html
I have reported the bug yesterday using gccbug but did not receive an email
confirming the report.
Therefore I'm filing it here again because I did not find it in the bug
database.
# 1 gcc-4.1.1-ppc.c
# 0 built-in
# 1 command line
# 1 gcc-4.1.1-ppc.c
# 15 gcc-4.1.1-ppc.c
# 1 /usr/include/assert.h 1 3 4
# 45 /usr/include/assert.h 3 4
extern void __eprintf (const char *, const char *, unsigned, const char *)
__attribute__ ((noreturn));
# 16 gcc-4.1.1-ppc.c 2
# 1 /scratch/lindig/lib/gcc/powerpc-apple-darwin7.9.0/4.1.0/include/stdarg.h
1 3 4
# 43 /scratch/lindig/lib/gcc/powerpc-apple-darwin7.9.0/4.1.0/include/stdarg.h
3 4
typedef __builtin_va_list __gnuc_va_list;
# 105
/scratch/lindig/lib/gcc/powerpc-apple-darwin7.9.0/4.1.0/include/stdarg.h 3 4
typedef __gnuc_va_list va_list;
# 22 gcc-4.1.1-ppc.c 2
extern int printf (char *, ...);
static int errors = 0;
static void failed( int line )
{ printf (failed in %s: %d\n, gcc-4.1.1-ppc.c, line); errors++; }
static union at6 { } vv6 = { };
static
struct et6
{
struct bt6
{
signed av6:6;
signed bv6:7;
signed cv6:6;
signed dv6:5;
unsigned char ev6;
unsigned int fv6;
long int gv6;
}
mv6;
unsigned long int nv6;
signed ov6:12;
signed pv6:3;
signed qv6:2;
signed rv6:10;
union ct6 { long int hv6; float iv6; float jv6; } sv6;
int *tv6;
union dt6 { double kv6; float lv6; } uv6;
}
wv6
=
{
{ 8, 9, 2, 4, '\x10', 67426805U, 1047191860L },
1366022414UL,
858,
1,
1,
305,
{ 1069379046L },
(int *) 358273621U,
{ 3318.041978 }
};
static double xv6 = 19239.101269;
static long long int yv6 = 1207859169L;
static int zv6 = 660195606;
static
union at6
callee_af6( struct et6 ap6, double bp6, long long int cp6, int dp6 )
{
((void) ((wv6.mv6.av6 == ap6.mv6.av6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 72, wv6.mv6.av6 == ap6.mv6.av6), 0)));
((void) ((wv6.mv6.bv6 == ap6.mv6.bv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 73, wv6.mv6.bv6 == ap6.mv6.bv6), 0)));
((void) ((wv6.mv6.cv6 == ap6.mv6.cv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 74, wv6.mv6.cv6 == ap6.mv6.cv6), 0)));
((void) ((wv6.mv6.dv6 == ap6.mv6.dv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 75, wv6.mv6.dv6 == ap6.mv6.dv6), 0)));
((void) ((wv6.mv6.ev6 == ap6.mv6.ev6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 76, wv6.mv6.ev6 == ap6.mv6.ev6), 0)));
((void) ((wv6.mv6.fv6 == ap6.mv6.fv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 77, wv6.mv6.fv6 == ap6.mv6.fv6), 0)));
((void) ((wv6.mv6.gv6 == ap6.mv6.gv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n, gcc-4.1.1-
ppc.c, 78, wv6.mv6.gv6 == ap6.mv6.gv6), 0)));
((void) ((wv6.nv6 == ap6.nv6) ? 0 : (__eprintf (%s:%u: failed assertion
`%s'\n, gcc-4.1.1-ppc.c, 79,
wv6.nv6 == ap6.nv6), 0)));
((void) ((wv6.ov6 == ap6.ov6) ? 0 : (__eprintf (%s:%u: failed assertion
`%s'\n, gcc-4.1.1-ppc.c, 80,
wv6.ov6 == ap6.ov6), 0)));
((void) ((wv6.pv6 == ap6.pv6) ? 0 : (__eprintf (%s:%u: failed assertion
`%s'\n, gcc-4.1.1-ppc.c, 81,
wv6.pv6 == ap6.pv6), 0)));
((void) ((wv6.qv6 == ap6.qv6) ? 0 : (__eprintf (%s:%u: failed assertion
`%s'\n, gcc-4.1.1-ppc.c, 82,
wv6.qv6 == ap6.qv6), 0)));
((void) ((wv6.rv6 == ap6.rv6) ? 0 : (__eprintf (%s:%u: failed assertion
`%s'\n, gcc-4.1.1-ppc.c, 83,
wv6.rv6 == ap6.rv6), 0)));
((void) ((wv6.sv6.hv6 == ap6.sv6.hv6) ? 0 : (__eprintf (%s:%u: failed
assertion `%s'\n,
[Bug c/23324] unsigned bitfield in struct not passed correctly as argument
--- Additional Comments From lindig at cs dot uni-sb dot de 2005-08-11 08:10 --- Created an attachment (id=9468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9468action=view) Test case to reproduce the bug. This is the same code that I included in the bug description. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From irar at il dot ibm dot com 2005-08-11 08:14 --- Created an attachment (id=9469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9469action=view) Patch Yes, you are right, I should check the type of the data-ref (array type in the first case). And instead of the assert I'll add the check that both data-refs are of pointer type in the second case. I'll submit the changes after testing. Thanks, Ira -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug c/23324] unsigned bitfield in struct not passed correctly as argument
--- Additional Comments From lindig at cs dot uni-sb dot de 2005-08-11
08:15 ---
The bitfield mv7 is actually signed, not unsigned:
struct et7
{
struct dt7 { float iv7; unsigned short int jv7; } kv7;
float lv7[0];
signed mv7:9;
short int nv7;
double ov7;
float pv7;
}
yv7
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug tree-optimization/23297] immediate uses hosed after CCP
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 08:30 --- Now that you describe what is going wrong, I remember having this problem earlier. And even a fix. Ugh. Sorry for bothering you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23297
[Bug tree-optimization/23297] immediate uses hosed after CCP
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 08:32 --- Created an attachment (id=9470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9470action=view) patch fixing the problem This is the patch which fixes the problem. Whether this situation can happen with an unpatched mainline is unclear to me. What to do with bugreports like this as well ;) Leaving UNCONFIRMED. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23297
[Bug target/23289] [4.1 Regression] tail call optimization not performed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 08:59 --- Subject: Bug 23289 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 08:59:22 Modified files: gcc: ChangeLog gcc/config/i386: i386.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: tailcall-1.c Log message: 2005-08-11 Richard Guenther [EMAIL PROTECTED] PR target/23289 * config/i386/i386.c (ix86_function_ok_for_sibcall): Handle cases where we call to/from functions returning void. * gcc.target/i386/tailcall-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9700r2=2.9701 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gccr1=1.851r2=1.852 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5906r2=1.5907 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/tailcall-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23289
[Bug target/23289] [4.1 Regression] tail call optimization not performed
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 09:03 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23289
[Bug tree-optimization/23153] [4.1 Regression] code size regression from 4.0 on x86
-- Bug 23153 depends on bug 23289, which changed state. Bug 23289 Summary: [4.1 Regression] tail call optimization not performed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23289 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug target/18649] terminate called after throwing - IOT/Abort trap (core dumped)
--- Additional Comments From jkj at sco dot com 2005-08-11 09:18 --- On UnixWare I have a very similar failure. It seems to be -fPIC that's wreaking the havoc. I have an almost identical test case, and it aborts with: terminate called after throwing an instance of 'int' terminate called recursively This only happens when compiling a2.cpp with -fPIC and producing a .so. If you link the two together, it works fine. This was with 3.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
[Bug c++/23219] [4.1 Regression] ICE: Segmentation fault in decl_namespace_context
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 09:24 --- Subject: Bug 23219 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 09:23:57 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: crash28.C Log message: cp: PR c++/23219 * name-lookup.c (pushtag): Process the template type before altering the identifier lookup fields. Remove unreachable code creating an empty stub decl. testsuite: PR c++/23219 * g++.dg/parse/crash28.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4846r2=1.4847 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.135r2=1.136 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5907r2=1.5908 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash28.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
[Bug c++/23219] [4.1 Regression] ICE: Segmentation fault in decl_namespace_context
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-11 09:29 --- Fixed mainline and 4.0 2005-08-11 Nathan Sidwell [EMAIL PROTECTED] PR c++/23219 * name-lookup.c (pushtag): Process the template type before altering the identifier lookup fields. Remove unreachable code creating an empty stub decl. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
[Bug c++/23219] [4.1 Regression] ICE: Segmentation fault in decl_namespace_context
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 09:31 --- Subject: Bug 23219 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-11 09:31:22 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: crash28.C Log message: cp: PR c++/23219 * name-lookup.c (pushtag): Process the template type before altering the identifier lookup fields. testsuite: PR c++/23219 * g++.dg/parse/crash28.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.74r2=1.4648.2.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.109.4.5r2=1.109.4.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.328r2=1.5084.2.329 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash28.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
[Bug rtl-optimization/23322] [4.1 regression] performance regression, possibly related to caching
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11
10:30 ---
I cannot confirm your observations, instead, with -O2 timings are about the
same for 4.0.2 (20050728) and 4.1.0 (20050803), while with -O3 the 4.0.2
compiler seems to be about 2x faster even if the tree optimizers do a better
job in the 4.1 case.
One difference is:
(4.1)
.L37:
movl$0, (%eax)
movl$1074266112, 4(%eax)
addl$8, %eax
cmpl%eax, %edx
jne .L37
vs.
(4.0)
fldlinit_value
.L16:
fstl(%eax)
addl$8, %eax
cmpl%eax, %ecx
jne .L16
(known bug, I think - andrew will know the PR)
The other one is
(4.0)
.L8:
fldz
xorl%eax, %eax
fstl-16(%ebp)
.p2align 4,,15
.L11:
faddl (%ebx,%eax,8)
incl%eax
cmpl%edx, %eax
fstl-16(%ebp)
jne .L11
fstp%st(0)
jmp .L10
vs.
(4.1)
fldz
xorl%eax, %eax
fstpl -16(%ebp)
jmp .L31
.p2align 4,,7
.L43:
fstp%st(0)
.L31:
fldl-16(%ebp)
faddl (%ebx,%eax,8)
incl%eax
cmpl%edx, %eax
fstl-16(%ebp)
jne .L43
which certainly explains the big difference. This is just
L37:;
result = 0.0;
n = 0;
L8:;
result = MEM[base: first, index: (double *) n, step: 8B] + result;
n = n + 1;
if (n != D.34008) goto L8; else goto L34;
btw. or
static double test0(double* first, double* last) {
double result = 0;
for (int n = 0; n last - first; ++n) result += first[n];
return result;
}
Note that compiling this function stand-alone both produce identical
(good) assembly:
fldz
xorl%eax, %eax
.p2align 4,,15
.L5:
faddl (%ecx,%eax,8)
incl%eax
cmpl%edx, %eax
jne .L5
so it looks to me that RTL optimization goes berzerk and messes things up
here. The cerr effect may have to to sth with aliasing (though again at
the RTL level, I think). IVOPTs dumps show
(4.0)
# result_67 = PHI result_32(19), 0.0(17);
# n_4 = PHI n_66(19), 0(17);
L6:;
D.32905_127 = (unsigned int) n_4;
D.32906_126 = (double *) D.32905_127;
D.32907_125 = D.32906_126 * 8B;
D.32908_124 = first_11 + D.32907_125;
D.32848_69 = D.32908_124;
# VUSE init_value_5;
# VUSE data_12;
# VUSE Data_129;
# VUSE cerr_3;
D.32849_64 = *D.32848_69;
result_32 = D.32849_64 + result_67;
n_66 = n_4 + 1;
if (n_66 != D.32844_140) goto L34; else goto L35;
(4.1)
# n_105 = PHI n_66(11), 0(9);
# result_103 = PHI result_65(11), 0.0(9);
L8:;
D.34086_22 = (double *) n_105;
# VUSE cerr_13;
# VUSE data_36;
# VUSE Data_27;
D.34003_64 = MEM[base: first_11, index: D.34086_22, step: 8B];
result_65 = D.34003_64 + result_103;
n_66 = n_105 + 1;
if (n_66 != D.34008_102) goto L33; else goto L34;
which shows there's no real difference in tree-level alias information.
For the separate function we do
# n_27 = PHI n_19(3), 0(1);
# result_25 = PHI result_18(3), 0.0(1);
L0:;
D.1814_2 = (double *) n_27;
# VUSE TMT.8_20;
D.1750_17 = MEM[base: first_7, index: D.1814_2, step: 8B];
result_18 = D.1750_17 + result_25;
n_19 = n_27 + 1;
if (n_19 != D.1744_24) goto L9; else goto L10;
though. I'll make this rtl-optimization until someone tries another
architecture.
--
What|Removed |Added
Component|target |rtl-optimization
Keywords||missed-optimization
Summary|performance regression, |[4.1 regression] performance
|possibly related to caching |regression, possibly related
||to caching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11
10:44 ---
We inline all and get
void bar() ()
{
char D.1777;
struct B * D.1776;
char D.1773;
union C D.1772;
bb 0:
D.1772.p = a;
D.1776_5 = D.1772.q;
D.1777_6 = D.1776_5-d;
D.1773_7 = D.1777_6;
*D.1773_7 = 0;
return;
}
where we access the padding between c and i in struct A through an
object of type B. This must be invalid code. Even if it is, the
gcc_unreachable () is probably not a good idea - Danny, how should
we deal with this? Ignore references to padding and just return
NULL from first_vi_for_offset?
There's a similar problem in get_constraint_for_component_ref which
I hit with array-aliasing and work-around by
*** get_constraint_for_component_ref (tree t
*** 2075,2082
}
/* assert that we found *some* field there. The user couldn't be
accessing *only* padding. */
!
! gcc_assert (curr);
}
else
if (dump_file (dump_flags TDF_DETAILS))
--- 2076,2084
}
/* assert that we found *some* field there. The user couldn't be
accessing *only* padding. */
! /* Still the user could access one past the end of an array
!embedded in a struct resulting in accessing *only* padding. */
! /* gcc_assert (curr); */
}
else
if (dump_file (dump_flags TDF_DETAILS))
--
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 10:53 --- With the patch we make _Z3barv: .LFB6: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: movb$0, a+1 popl%ebp ret out of it btw, which looks ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 11:01 --- Couldn't DOM do this at jump threading time? I.e. if (D.1286_3 D.1287_5) goto L3; else goto L1; L1:; if (D.1286_3 == D.1287_5) goto L3; else goto L2; during trying of threading through the jump at L1 merge the two conditionals? Just guessing... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-11 11:38 --- (In reply to comment #2) I cannot debug it further as I debugging with an optimized compiled. cd $GCC_SRC_DIR/gcc/java touch class.c parse.y cd $GCC_BLD_DIR make BOOT_CFLAGS='-g3 -O0' bubblestrap http://gcc.gnu.org/wiki/DebuggingGCC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 11:49 --- Subject: Bug 23230 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 11:49:27 Modified files: gcc/java : ChangeLog java-gimplify.c parse.y Log message: 2005-08-10 Andrew Haley [EMAIL PROTECTED] * java-gimplify.c (java_gimplify_modify_expr): Fix any pointer type mismatches to make legal GIMPLE. 2005-08-10 Robin Green [EMAIL PROTECTED] PR java/23230: * parse.y (maybe_use_access_method): Generalize check from java.lang.Object to any superclass of current_class Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1652r2=1.1653 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-gimplify.c.diff?cvsroot=gccr1=1.20r2=1.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gccr1=1.550r2=1.551 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug target/23322] [4.1 regression] performance regression, possibly related to caching
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:01 --- This is reg stack going funny so this is a target issue. -- What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug rtl-optimization/23324] unsigned bitfield in struct not passed correctly as argument
-- What|Removed |Added Component|c |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug rtl-optimization/23324] [4.1 Regression] unsigned bitfield in struct not passed correctly as argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:22 --- Confirmed, This looks like an aliasing issue on the rtl level as -O2 -fno-strict-aliasing works. This also worked on the 4.0 branch. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin7.9.0 | GCC host triplet|powerpc-apple-darwin7.9.0 | GCC target triplet|powerpc-apple-darwin7.9.0 |powerpc-*-darwin* Keywords||alias Last reconfirmed|-00-00 00:00:00 |2005-08-11 12:22:54 date|| Summary|unsigned bitfield in struct |[4.1 Regression] unsigned |not passed correctly as |bitfield in struct not |argument|passed correctly as argument Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug rtl-optimization/23324] [4.1 Regression] unsigned bitfield in struct not accessed correctly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:24 --- Oh, and this is related to how we inline and then also inline the values of the static const variables (with -ftree-store-ccp). -- What|Removed |Added Summary|[4.1 Regression] unsigned |[4.1 Regression] unsigned |bitfield in struct not |bitfield in struct not |passed correctly as argument|accessed correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug rtl-optimization/23324] [4.1 Regression] unsigned bitfield in struct not accessed correctly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:34 --- CSE1 is where the differenet is between -O2 and -O2 -fno-strict-aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug fortran/23323] Internal compiler error with CHARACTER functions and -fdefault-integer-8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:47 --- *** This bug has been marked as a duplicate of 20971 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23323
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 12:47 --- *** Bug 23323 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||georg dot denk at infineon ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-11
12:55 ---
Subject: Re: [4.1 Regression] ICE in
first_vi_for_offset, at tree-ssa-structalias.c:2858
On Thu, 2005-08-11 at 10:44 +, rguenth at gcc dot gnu dot org wrote:
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11
10:44 ---
We inline all and get
void bar() ()
{
char D.1777;
struct B * D.1776;
char D.1773;
union C D.1772;
bb 0:
D.1772.p = a;
D.1776_5 = D.1772.q;
D.1777_6 = D.1776_5-d;
D.1773_7 = D.1777_6;
*D.1773_7 = 0;
return;
}
where we access the padding between c and i in struct A through an
object of type B. This must be invalid code. Even if it is, the
gcc_unreachable () is probably not a good idea - Danny, how should
we deal with this? Ignore references to padding and just return
NULL from first_vi_for_offset?
I know what to do here. I've just been waiting as long as possible to
remove the assert because it also catches real bugs.
I actually plan on removing it today, and have bootstrapped and tested a
patch to do so.
There's a similar problem in get_constraint_for_component_ref which
I hit with array-aliasing and work-around by
*** get_constraint_for_component_ref (tree t
*** 2075,2082
}
/* assert that we found *some* field there. The user couldn't be
accessing *only* padding. */
!
! gcc_assert (curr);
}
else
if (dump_file (dump_flags TDF_DETAILS))
--- 2076,2084
}
/* assert that we found *some* field there. The user couldn't be
accessing *only* padding. */
! /* Still the user could access one past the end of an array
!embedded in a struct resulting in accessing *only* padding. */
! /* gcc_assert (curr); */
You are right, but this can only occur with your patch, since it
wouldn't have had fields before, and thus it would have overlapped with
the actual variable, giving the right answer. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 13:04 --- Subject: Bug 23230 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-11 13:03:51 Modified files: gcc/java : ChangeLog parse.y Log message: 2005-08-10 Robin Green [EMAIL PROTECTED] PR java/23230: * parse.y (maybe_use_access_method): Generalize check from java.lang.Object to any superclass of current_class Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1556.2.26r2=1.1556.2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.528.6.1r2=1.528.6.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug rtl-optimization/15265] delete_output_reload deletes necessary insn
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 13:07 --- 4.1.0, 4.0.2 and 3.4.5 work with all -O0 -O1 -O2 -O3. gcc (GCC) 3.3.3 (SuSE Linux) and gcc 3.3.6 abort with -O1. I guess this is RESOLVED FIXED as far as gcc bugzilla is concerned? -- What|Removed |Added Known to fail||3.3.3 3.3.6 Known to work||4.1.0 4.0.2 3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15265
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:26 --- Fixed in 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 23230, which changed state. Bug 23230 Summary: Wrong this used when call made to superclass which is also superclass of enclosing class http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug libfortran/23321] Direct unformatted read beyond EOF cores
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:31 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-11 13:31:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23321
[Bug other/23325] New: gcc 64 bit build problem
Platform : AMD 64bit Opteron. O/S : Redhat linux Advanced Server 3.0 Kernel Version : 2.4.21-1.1931.2.393.ent When we try to build gcc 3.4.3, the build fails giving the following error. /usr/bin/ld: cannot open crti.o: No such file or directory collect2: ld returned 1 exit status make[2]: *** [32/libgcc_s_32.so] Error 1 make[2]: *** Waiting for unfinished jobs ranlib 32/libgcc.a But crti.o is present at the path /usr/lib64/crti.o -- Summary: gcc 64 bit build problem Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sos at cal dot interrasystems dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23325
[Bug target/23325] gcc 64 bit build problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:33 --- This is not a bug, it is trying to compile the 32bit multilib. Use either --disable-multilib or install the 32bit libraries. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23325
[Bug tree-optimization/22555] array in struct disables salias subvars for other fields
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 13:39 --- Ok, patch finally has all latent problems fixed. Maybe we can consider this for 4.2. -- What|Removed |Added OtherBugsDependingO||23111 nThis|| URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg00685.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22555
[Bug fortran/23318] program works correctly with -g option but fails with -O option on LINUX
--- Additional Comments From dir at lanl dot gov 2005-08-11 13:41 --- In pulling the routines out, I forgot to set n1=1 and zero the others, but it does not affect the results. The rest of the warning messages indicate that ftnchek does not know how to correctly handle a program that does its own dynamic memory management. In this case, there is enough information for ftnchek to tell that the program is correct - if it analyzed the program and did the math symbolically. I suspect that it is impossible to make ftnchek happy with this type of program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23318
[Bug fortran/23318] program works correctly with -g option but fails with -O option on LINUX
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:43 --- Hmm, -fno-tree-loop-im fixes it for some reason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23318
[Bug tree-optimization/23318] [4.1 Regression] program works correctly with -g option but fails with -O option on LINUX
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:48 --- Hmm, this worked in 4.0.0. -- What|Removed |Added Component|fortran |tree-optimization GCC host triplet|Suse Linux professional 9.3 | GCC target triplet||i686-linux Keywords||alias, wrong-code Summary|program works correctly with|[4.1 Regression] program |-g option but fails with -O |works correctly with -g |option on LINUX |option but fails with -O ||option on LINUX Target Milestone|--- |4.1.0 Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23318
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 13:50 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 13:50:13 Modified files: gcc/fortran: ChangeLog gfortran.h trans-decl.c trans.c trans.h libgfortran: ChangeLog Makefile.am Makefile.in libgfortran.h libgfortran/io : format.c libgfortran/runtime: error.c main.c Added files: gcc/testsuite/gfortran.dg: runtime_warning_1.f90 libgfortran/runtime: compile_options.c Log message: PR libfortran/20006 * gfortran.h: Add is_main_program member to symbol_attribute. * trans-decl: Add a gfor_fndecl_set_std tree. (gfc_build_builtin_function_decls): Create it. (gfc_generate_function_code): Add this call at the beginning of the main program. * trans.c (gfc_generate_code): Move main_program and attr. * trans.h: Add declaration for gfor_fndecl_set_std. * Makefile.am: Add file runtime/compile_options.c. * Makefile.in: Regenerate. * libgfortran.h: Create structure compile_options_t. Define the compile_options variable and GFC_STD_ macros. * runtime/compile_options.c: New file. * runtime/error.c (notify_std): New function. * runtime/main.c (init): Call init_compile_options during initialization. * io/format.c: Use the new notify_std function for the $ descriptor extension. * gfortran.dg/runtime_warning_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.519r2=1.520 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gccr1=1.79r2=1.80 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gccr1=1.65r2=1.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.c.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gccr1=1.31r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/runtime_warning_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.282r2=1.283 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gccr1=1.40r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gccr1=1.42r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gccr1=1.28r2=1.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gccr1=1.13r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/compile_options.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/error.c.diff?cvsroot=gccr1=1.11r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/main.c.diff?cvsroot=gccr1=1.7r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-11 13:52 --- This bug is fixed: we now have a framework for runtime warnings about standard conformance, and we use it in this case. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 13:53 --- This seems like a bug in GNU make and should reported there instead as it could cause other issues. Seems like this should be turned off by default and have a way to turn it on for these makefiles who wants it. -- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23292
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 13:53 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-11 13:53:22 Modified files: gcc/fortran: ChangeLog gfortran.h trans-decl.c trans.c trans.h gcc/testsuite : ChangeLog libgfortran: ChangeLog Makefile.am Makefile.in aclocal.m4 libgfortran.h libgfortran/io : format.c libgfortran/runtime: error.c main.c Log message: PR libfortran/20006 * gfortran.h: Add is_main_program member to symbol_attribute. * trans-decl: Add a gfor_fndecl_set_std tree. (gfc_build_builtin_function_decls): Create it. (gfc_generate_function_code): Add this call at the beginning of the main program. * trans.c (gfc_generate_code): Move main_program and attr. * trans.h: Add declaration for gfor_fndecl_set_std. * Makefile.am: Add file runtime/compile_options.c. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * libgfortran.h: Create structure compile_options_t. Define the compile_options variable and GFC_STD_ macros. * runtime/compile_options.c: New file. * runtime/error.c (notify_std): New function. * runtime/main.c (init): Call init_compile_options during initialization. * io/format.c: Use the new notify_std function for the $ descriptor extension. * gfortran.dg/runtime_warning_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.104r2=1.335.2.105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.58.2.13r2=1.58.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.54.2.4r2=1.54.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.21.10.1r2=1.21.10.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23.2.4r2=1.23.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.329r2=1.5084.2.330 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.76r2=1.163.2.77 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.29.10.7r2=1.29.10.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.30.10.6r2=1.30.10.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/aclocal.m4.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.6.12.3r2=1.6.12.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23.8.3r2=1.23.8.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9.12.3r2=1.9.12.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/error.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=1.9.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/main.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.6r2=1.6.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug target/23322] [4.1 regression] performance regression, possibly related to caching
-- What|Removed |Added CC||roger at eyesopen dot com Target Milestone|--- |4.1.0 Version|4.0.1 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug libgcj/23292] libjava build fails with recent version of GNU Make
-- What|Removed |Added 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=23292
[Bug tree-optimization/22471] [4.1 Regression] corrupted profile info with -O3 -fprofile-use
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 14:15 --- Is this fixed? profiledbootstrap works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22471
[Bug libstdc++/22205] [4.1 Regression] errors debug mode on aix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 14:16 --- A real good question is why does debug mode need link once at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 14:18 --- As I mentioned this effects more than AIX, though AIX's limits are lower than most other OS's -- What|Removed |Added GCC host triplet|powerpc-ibm-aix | GCC target triplet|powerpc-ibm-aix | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22554
[Bug libfortran/22143] missing kinds 1 and 2 for eoshift and cshift
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
[Bug target/23250] [4.0/4.1 regression] 4.0.1 switch -mcallee-super-interworking generating wrong code for ARM7TDMI
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 14:20 --- Subject: Bug 23250 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 14:20:25 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/23250 * arm.c (arm_override_options): If the user has selected callee-super- interworking, then enable normal interworking. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9703r2=2.9704 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gccr1=1.471r2=1.472 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23250
[Bug target/23250] [4.0/4.1 regression] 4.0.1 switch -mcallee-super-interworking generating wrong code for ARM7TDMI
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 14:33 --- Subject: Bug 23250 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-11 14:33:19 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/23250 * arm.c (arm_override_options): If the user has selected callee-super- interworking, then enable normal interworking. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.362r2=2.7592.2.363 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.430.2.2r2=1.430.2.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23250
[Bug target/23250] [4.0/4.1 regression] 4.0.1 switch -mcallee-super-interworking generating wrong code for ARM7TDMI
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-11 14:35 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23250
[Bug target/23322] [4.1 regression] performance regression, possibly related to caching
--- Additional Comments From roger at eyesopen dot com 2005-08-11 14:56 --- I'll take a look, but on first inspection this looks more like a register allocation issue than a reg-stack problem. In the first (4.0) case, the accumulator result is assigned a hard register in the loop, whilst in the second (4.1) it is being placed in memory, at -16(%ebp). This may also explain why extracting that loop into a stand-alone function produces optimal/original code, as the register allocator gets less confused by other influences in the function. The extracted code is also even better than 4.0's, as it avoids writing result to memory on each iteration (store sinking). The second failure does show an interesting reg-stack/reg-alloc interaction though. The hot accumulator value is live on the backedge and the exit edge of the loop but not on the incoming edge. Clearly, the best fix is to make this value live on the incoming edge, but failing that it is actually better to prevent it being live on the back and exit edges, and add compensation code after the loop. i.e. if the store to result in the loop used fstpl, you wouldn't need to fstp %st(0) on each loop iteration, but would instead need a compensating fldl after the loop. I'm not sure how easy it would be to teach GCC's register allocation to take these considerations into account, or failing that, whether reg-stack could be tweaked/hacked to locally fix this up. But the fundamental problem is that reg-alloc should assign result to a hard resigster as it clearly knows there are enough available in that block. reg-stack.c is just doing what its told, and in this case its being told to do something stupid. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-11 14:56:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug tree-optimization/23326] New: [4.0 Regression] Wrong code from forwprop
The following testcase reduced from Kopete is miscompiled at -O2
struct Bar { bool is() const; int status() const; };
void foobar(void);
void foobar2(void);
void Foo(const Bar x, const Bar y)
{
const bool wasOffline = !x.is();
const bool isOffline = !y.is();
if (wasOffline || y.status() == 10)
foobar();
if (wasOffline != isOffline)
foobar2();
}
.t23.mergephi:
bb 0:
D.1589_3 = is (x_2);
wasOffline_4 = !D.1589_3;
D.1590_6 = is (y_5);
isOffline_7 = !D.1590_6;
if (wasOffline_4) goto L1; else goto L0;
L0:;
D.1596_10 = status (y_5);
if (D.1596_10 == 10) goto L1; else goto L5;
L1:;
foobar ();
L5:;
if (wasOffline_4 != isOffline_7) goto L6; else goto L7;
L6:;
foobar2 ();
L7:;
return;
.t24.forwprop:
bb 0:
D.1589_3 = is (x_2);
D.1590_6 = is (y_5);
isOffline_7 = !D.1590_6;
if (D.1589_3 == 0) goto L1; else goto L0;
L0:;
D.1596_10 = status (y_5);
if (D.1596_10 == 10) goto L1; else goto L5;
L1:;
foobar ();
L5:;
if (D.1589_3 != 0) goto L6; else goto L7;
L6:;
foobar2 ();
L7:;
return;
note that the comparison preceding foobar2() is hosed now,
we even don't use isOffline or D.1590 anymore.
--
Summary: [4.0 Regression] Wrong code from forwprop
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
-- What|Removed |Added Known to fail||4.0.2 Known to work||4.1.0 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 15:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-11 15:29:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Additional Comments From law at redhat dot com 2005-08-11 15:43 --- Subject: Re: [tree-ssa] Merge two ifs if one subsumes the other. On Thu, 2005-08-11 at 11:01 +, rguenth at gcc dot gnu dot org wrote: --- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-11 11:01 --- Couldn't DOM do this at jump threading time? I.e. if (D.1286_3 D.1287_5) goto L3; else goto L1; L1:; if (D.1286_3 == D.1287_5) goto L3; else goto L2; during trying of threading through the jump at L1 merge the two conditionals? Jump threading isn't particularly well suited for this kind of optimization. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 15:51 --- Oh, this is truely fixed for 4.1 and not a latent bug there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Additional Comments From trt at acm dot org 2005-08-11 15:52 --- I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643 is closely related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug target/23150] 20050713-1.c fails on arm-none-eabi with -O2 or -Os.
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-11 15:55 --- The problem seems to be related to the fact that in this configuration the compiler has decided that bar2 can tailcall foo2. In order to do this it then has to swap x y in place (well, with one temporary copy on the stack). But the code emitted to do this appears to be completely bogus in the first rtl dump. For some reason this same code does not use a tailcall when -mabi=atpcs is used. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-08-11 15:55:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23150
[Bug regression/23327] New: Improper removal of struct field assignments by optimizer
GCC 4.0.0 and later optimize out struct assignments inappropriately when the
struct is used as an input to an asm(). For example, in:
struct {int a,b} args;
a
--
Summary: Improper removal of struct field assignments by
optimizer
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla at achurch dot org
CC: gcc-bugs at gcc dot gnu dot org
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=23327
[Bug regression/23328] New: Improper removal of struct field assignments by optimizer
GCC 4.0.0 and later optimize out struct assignments inappropriately when the
struct is used as an input to an asm(). For example, in:
int foo(int a, int b) {
struct {int a,b} args;
args.a = a; args.b = b;
asm(... : : S (args));
}
the args.a and args.b assignments are optimized out (with -O3 at least) despite
the structure being specified as an input to the asm(). See attached files.
--
Summary: Improper removal of struct field assignments by
optimizer
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla at achurch dot org
CC: gcc-bugs at gcc dot gnu dot org
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=23328
[Bug regression/23327] Improper removal of struct field assignments by optimizer
--- Additional Comments From gcczilla at achurch dot org 2005-08-11 16:00 --- Sorry, accidentally submitted while typing--refiled as bug 23328. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23327
[Bug regression/23328] Improper removal of struct field assignments by optimizer
--- Additional Comments From gcczilla at achurch dot org 2005-08-11 16:01 --- Created an attachment (id=9473) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9473action=view) Sample source file demonstrating bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23328
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 16:03 --- Created an attachment (id=9474) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9474action=view) Patch which fixes but needs testing This patch fixes the problem by continuing if we don't have a SSA_NAME or zero/one in the conditional. Richard if you could test this for me, that would be nice. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug rtl-optimization/15265] delete_output_reload deletes necessary insn
--- Additional Comments From matz at suse dot de 2005-08-11 16:13 --- I don't think this is actually fixed in reload1.c. Perhaps it is hidden by other changes, so that the particular miscompilation doesn't happen anymore, but even HEAD reload1.c contains the questionable double counting of inherited operands. Might be with enough work (perhaps by disabling some tree-ssa passes, but retaining -O1) we can still make it fail with mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15265
[Bug regression/23328] Improper removal of struct field assignments by optimizer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 16:48 --- The code is invalid as you don't say you going to access memory. either mark the asm as clobbers memory (which is not fully true) or use the following replacement asm (which works): asm(mov 0(%%esi),%%eax; mov 4(%%esi),%%edx; add %%edx,%%eax; : =a (c) : S (args) ,m (args) : edx); It says to the compiler that args is accessed as memory. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23328
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- Bug 22368 depends on bug 23315, which changed state. Bug 23315 Summary: java produces mismatch types in MODIFY_EXPR, down cast http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23315 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug java/23315] java produces mismatch types in MODIFY_EXPR, down cast
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 16:50 --- This was fixed by: 2005-08-10 Andrew Haley [EMAIL PROTECTED] * java-gimplify.c (java_gimplify_modify_expr): Fix any pointer type mismatches to make legal GIMPLE. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23315
[Bug java/23314] java produces mismatch types in MODIFY_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 16:50 --- Fixed by: 2005-08-10 Andrew Haley [EMAIL PROTECTED] * java-gimplify.c (java_gimplify_modify_expr): Fix any pointer type mismatches to make legal GIMPLE. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- Bug 22368 depends on bug 23314, which changed state. Bug 23314 Summary: java produces mismatch types in MODIFY_EXPR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug target/22225] Tru64 UNIX testsuite failure: gcc.dg/vect/pr18536.c: ICE in in alphaev4_insn_pipe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 16:56 --- Subject: Bug 5 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 16:56:33 Modified files: gcc: ChangeLog gcc/config/alpha: alpha.c Log message: PR target/5 * config/alpha/alpha.c (alphaev4_insn_pipe): Add take pipes for insn types not present on ev4. (alphaev5_insn_pipe): Similarly. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9704r2=2.9705 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gccr1=1.433r2=1.434 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug middle-end/21992] [4.1 regression] [unit-at-a-time] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From hp at gcc dot gnu dot org 2005-08-11 16:59 --- Clarification to comment #18; the newly-enabled-for-all-targets try-catch-8.m (PR 23306) fails (so there was *one* failure in the objc testsuite at the time the above commit was made). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug target/22225] Tru64 UNIX testsuite failure: gcc.dg/vect/pr18536.c: ICE in in alphaev4_insn_pipe
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-11 16:59 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug target/22225] Tru64 UNIX testsuite failure: gcc.dg/vect/pr18536.c: ICE in in alphaev4_insn_pipe
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug rtl-optimization/15265] delete_output_reload deletes necessary insn
--- Additional Comments From giovannibajo at libero dot it 2005-08-11 17:05 --- Bernd, do you believe this is taken care of by the reload branch? -- What|Removed |Added CC||bernds at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15265
[Bug tree-optimization/23329] New: hack in may_propagate_copy should be able to removed
The hack in may_propagate_copy: /* FIXME. GIMPLE is allowing pointer assignments and comparisons of pointers that have different alias sets. This means that these pointers will have different memory tags associated to them. If we allow copy propagation in these cases, statements de-referencing the new pointer will now have a reference to a different memory tag with potentially incorrect SSA information. This was showing up in libjava/java/util/zip/ZipFile.java with code like: struct java.io.BufferedInputStream *T.660; struct java.io.BufferedInputStream *T.647; struct java.io.InputStream *is; struct java.io.InputStream *is.662; [ ... ] T.660 = T.647; is = T.660; -- This ought to be type-casted is.662 = is; Also, f/name.c exposed a similar problem with a COND_EXPR predicate that was causing DOM to generate and equivalence with two pointers of alias-incompatible types: struct _ffename_space *n; struct _ffename *ns; [ ... ] if (n == ns) goto lab; ... lab: return n; I think that GIMPLE should emit the appropriate type-casts. For the time being, blocking copy-propagation in these cases is the safe thing to do. */ Should be able to removed now as both the DOM and java front-ends issues have been fixed now. PR 22368 referenced the bugs which were filed so this hack could be removed. Even though PR 22368 references more than what is needed to remove this hack, I am going to mark this new bug as depending on that bug. -- Summary: hack in may_propagate_copy should be able to removed Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org BugsThisDependsOn: 22368 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- What|Removed |Added OtherBugsDependingO||23329 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug other/22368] [meta-bugs] mis-match types in GCC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 17:06 --- (In reply to comment #6) Note I think I already fixed the DOM problem in PR 22335. And now the java front-end bug has been fixed, maybe I should go ahead and test a patch to remove the hack from may_propagate_copy. I also filed PR 23329 for the removal of the hack. -- What|Removed |Added OtherBugsDependingO|23329 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
-- What|Removed |Added BugsThisDependsOn|22368 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
-- What|Removed |Added BugsThisDependsOn||22368 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug tree-optimization/23330] New: FIXME from passes.c: pass_may_alias should be a TODO item
FIXME from passes.c: /* FIXME: SRA may generate arbitrary gimple code, exposing new aliased and call-clobbered variables. As mentioned below, pass_may_alias should be a TODO item. */ /* FIXME: May alias should a TODO but for 4.0.0, we add may_alias right after fold builtins which can create arbitrary GIMPLE. */ Just a bug to track progress on this FIXME. -- Summary: FIXME from passes.c: pass_may_alias should be a TODO item Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23330
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From cvs-commit at developer dot classpath dot org 2005-08-11 17:11 --- Subject: Bug 23238 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey [EMAIL PROTECTED] 05/08/11 16:40:53 Modified files: . : ChangeLog configure.ac lib: gen-classlist.sh.in Log message: For PR classpath/23238: * lib/gen-classlist.sh.in: Use @SHELL@; invoke split-for-gcj.sh with it. * configure.ac (SH): Removed subst. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4384tr2=1.4385r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/configure.ac.diff?tr1=1.97tr2=1.98r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/gen-classlist.sh.in.diff?tr1=1.28tr2=1.29r1=textr2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug middle-end/23312] [4.0/4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 17:12 --- Subject: Bug 23312 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 17:12:31 Modified files: gcc: ChangeLog gimplify.c Log message: PR middle-end/23312 * gimplify.c (gimplify_one_sizepos): Check for INTEGER_TYPE before using TYPE_IS_SIZETYPE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9705r2=2.9706 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.144r2=2.145 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Additional Comments From giovannibajo at libero dot it 2005-08-11 17:13 --- I don't think the hack should be removed until a verifier is committed, otherwise we could still get wrong code for other yet-to-be-fixed cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug middle-end/23312] [4.0/4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-11 17:15:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug middle-end/23312] [4.0/4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-11 17:16 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug tree-optimization/23331] New: FIXME from tree-ssa-ccp: dealing with a[3]
/* We can get here for out-of-range string constant accesses,
such as _[3]. Bail out of the entire substitution search
and arrange for the entire statement to be replaced by a
call to __builtin_trap. In all likelihood this will all be
constant-folded away, but in the meantime we can't leave with
something that get_expr_operands can't understand. */
t = base;
STRIP_NOPS (t);
if (TREE_CODE (t) == ADDR_EXPR
TREE_CODE (TREE_OPERAND (t, 0)) == STRING_CST)
{
/* FIXME: Except that this causes problems elsewhere with dead
code not being deleted, and we die in the rtl expanders
because we failed to remove some ssa_name. In the meantime,
just return zero. */
/* FIXME2: This condition should be signaled by
fold_read_from_constant_string directly, rather than
re-checking for it here. */
return integer_zero_node;
}
Just a bug to track progress on this FIXME.
--
Summary: FIXME from tree-ssa-ccp: dealing with a[3]
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23331
[Bug tree-optimization/23134] Address escapes even though the called function does not cause it to escape
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 17:20 --- I think the FIXME in tree-ssa-operands.c is the issue here: /* FIXME - if we have better information from the static vars analysis, we need to make the cache call site specific. This way we can have the performance benefits even if we are doing good optimization. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23134
[Bug gcov/profile/23332] New: FIXME in tree-profile.c: tree_gen_const_delta_profiler not implemented
static void
tree_gen_const_delta_profiler (histogram_value value ATTRIBUTE_UNUSED,
unsigned tag ATTRIBUTE_UNUSED,
unsigned base ATTRIBUTE_UNUSED)
{
/* FIXME implement this. */
#ifdef ENABLE_CHECKING
internal_error (unimplemented functionality);
#endif
gcc_unreachable ();
}
bug to track progress on this FIXME.
--
Summary: FIXME in tree-profile.c: tree_gen_const_delta_profiler
not implemented
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gcov/profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23332
[Bug c++/23333] New: accepts invalid pure specifier
testcase:
class a
{
virtual void f() = 0L;
};
See FIXME in parse.c:
/* FIXME: Unfortunately, this will accept `0L' and `0x00' as well.
We need to get information from the lexer about how the number
was spelled in order to fix this problem. */
return integer_zero_node;
--
Summary: accepts invalid pure specifier
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Additional Comments From law at redhat dot com 2005-08-11 17:29 --- Subject: Re: [tree-ssa] Merge two ifs if one subsumes the other. On Thu, 2005-08-11 at 15:52 +, trt at acm dot org wrote: --- Additional Comments From trt at acm dot org 2005-08-11 15:52 --- I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643 is closely related. It's related. However, there is a key difference. In 21643, the object being tested is a scalar and thus should be subject to optimization by fold-const.c's range checking optimizations. ie, the merging of the conditions in the test should occur well before the SSA optimization path is run. In 15353 the object being tested is a memory reference and thus we can not safely merge the tests until later in the optimization path (after we've exposed the memory loads and proved they're equivalent). jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/22471] [4.1 Regression] corrupted profile info with -O3 -fprofile-use
--- Additional Comments From janis at gcc dot gnu dot org 2005-08-11 17:29 --- Mainline GCC built last night successfully compiles and runs the SPEC CPU2000 tests that failed earlier. If anyone cares I can find out which patch fixed it, otherwise we can just close this as magically fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22471
[Bug tree-optimization/22471] [4.1 Regression] corrupted profile info with -O3 -fprofile-use
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 17:31 --- This was most likely fixed by the following patches: 2005-07-28 Jan Hubicka [EMAIL PROTECTED] * Makefile.in (rtl-profile.o): Kill all traces of it. 2005-08-03 Jan Hubicka [EMAIL PROTECTED] * cfgloop.h (DLTHE_FLAG_COMPLETTE_PEEL): New flag. * cfgloopmanip.c (duplicate_loop_to_header_edge): Special case profile updating for complette unrolling. * loop-unroll.c (peel_loop_completely): Use it. * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Likewise. (tree_unroll_loops_completely): Disable code growing unrolling of cold loops. 2005-08-02 Jan Hubicka [EMAIL PROTECTED] * tree-ssa-dom.c (thread_across_edge): Remove updating here. * tree-ssa-threadupdate.c (thread_block): Add it here. 2005-08-01 Jan Hubicka [EMAIL PROTECTED] * profile.c (compute_value_histograms): Fix thinko. * value-prof.c: Include toplev.h (check_counter): New function. (tree_divmod_fixed_value_transform, tree_mod_pow2_value_transform, tree_mod_subtract_transform): Add sanity check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22471
[Bug gcov/profile/23334] New: FIXME in coverage.c: use build_constructor directly
coverage.c: /* FIXME: use build_constructor directly. */ coverage.c: /* FIXME: use build_constructor directly. */ coverage.c: /* FIXME: use build_constructor directly. */ coverage.c: /* FIXME: use build_constructor directly. */ coverage.c: /* FIXME: use build_constructor directly. */ coverage.c: /* FIXME: use build_constructor directly. */ bug to track those FIXMEs. -- Summary: FIXME in coverage.c: use build_constructor directly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23334
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-08-11 17:43 --- I'll do that. Though + /* If we don't have NE_EXPR/NE_EXPR x INT_CST, then we cannot +optimize this case. */ + if ((cond_code == NE_EXPR || cond_code == EQ_EXPR) + TREE_CODE (TREE_OPERAND (cond, 1)) != INTEGER_CST) + continue; should probably read + /* If we don't have NE_EXPR/EQ_EXPR x INT_CST, then we cannot +optimize this case. */ + if (!((cond_code == NE_EXPR || cond_code == EQ_EXPR) +TREE_CODE (TREE_OPERAND (cond, 1)) == INTEGER_CST)) + continue; because else we might get f.i. LE_EXPR passing through? Maybe the little context confuses me here, though. I'll have a look before testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-11 17:45 --- Subject: Re: [4.0 Regression] Wrong code from forwprop On Aug 11, 2005, at 1:43 PM, rguenth at tat dot physik dot uni-tuebingen dot de wrote: because else we might get f.i. LE_EXPR passing through? Maybe the little context confuses me here, though. We will never get LE_EXPR here as this is always a boolean type. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/23335] New: out of ssa does not delete single def single use variable
The .t82.uncprop dump looks like this: L16:; D.15800_45 = *params_11; __nptr_47 = D.15800_45; D.15802_50 = __strtol_internal (__nptr_47, 0B, 10, 0); mult_55 = mult_1 * D.15802_50; goto bb 15 (L8); L17:; D.15800_29 = *params_11; __nptr_31 = D.15800_29; D.15807_34 = __strtol_internal (__nptr_31, 0B, 10, 0); D.15790_39 = screen_16-whichVwin; D.15791_40 = D.15790_39-f_height; mult_41 = D.15807_34 * D.15791_40; goto bb 15 (L8); L18:; D.15811_25 = screen_16-scrolllines; D.15790_26 = screen_16-whichVwin; D.15791_27 = D.15790_26-f_height; mult_28 = D.15811_25 * D.15791_27; goto bb 15 (L8); L6:; D.15698_10 = gw_4-core.parent; D.15697_13 = AmountToScroll (D.15698_10, params_11, nparams_12); # D.15697_3 = PHI 0(3), mult_41(12), D.15697_13(14), 0(0), mult_55(11), mult_28(13); L8:; return D.15697_3; and the .t87.final_cleanup dump looks like: L16:; D.15802 = __strtol_internal (*params, 0B, 10, 0); mult.78 = mult * D.15802; D.15697 = mult.78; goto bb 17 (L26); L17:; D.15807 = __strtol_internal (*params, 0B, 10, 0); mult.77 = D.15807 * screen-whichVwin-f_height; D.15697 = mult.77; goto bb 17 (L26); L18:; mult.76 = screen-scrolllines * screen-whichVwin-f_height; D.15697 = mult.76; goto bb 17 (L26); L6:; D.15697 = AmountToScroll (gw-core.parent, params, nparams); goto bb 17 (L26); L8:; D.15697 = 0; L26:; return D.15697; Note that the mult.76, mult.77, mult.78 have a single use and a single def, they could be eliminated. Preprocessed code will be attached. The compilation flags were -O2 -march=i686 The function to look at is AmmountToScroll -- Summary: out of ssa does not delete single def single use variable Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23335
