[Bug target/19774] New: VLA's vs SjLj EH unwind
The following testcase fails when using sjlj EH unwind (mingw32
compiler) but succeeds when using Dwarf2 EH unwind (also mingw with
sources modified to enable Dwarf2).
Is this related to PR 19771?
/* sjlj_vla.cc */
extern "C" void abort(void);
void foo()
{
int size = 1;
int a[size];
a[0] = 0;
try
{
throw 0;
}
catch (int i)
{
}
if (a[0] != 0)
abort();
}
int main()
{
foo();
}
--
Summary: VLA's vs SjLj EH unwind
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19774
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-02-03 09:03 --- Subject: Re: gnat tools not buildable cross > Arnauds: > checking for .preinit_array/.init_array/.fini_array support... yes For the record, it's Laurent's, not Arno's Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug middle-end/19331] [4.0 Regression] Inefficient code generated for bitfield assignment
--- Additional Comments From giovannibajo at libero dot it 2005-02-03 09:27 --- Patch posted by Roger: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00205.html (thanks!) -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sayle at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19331
[Bug middle-end/19775] New: [3.3 regression] sqrt(pow(x,y)) != pow(x,y*0.5)
This one should not abort:
#include
#include
int main()
{
double x = -1.0;
if (sqrt(pow(x,2)) != 1.0)
abort();
return 0;
}
but both, 3.4.4 and 4.0.0 do sqrt(pow(x,y)) -> pow(x,y*0.5)
which in this case means sqrt(1.0) -> -1.0.
Ouch.
--
Summary: [3.3 regression] sqrt(pow(x,y)) != pow(x,y*0.5)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19775
[Bug middle-end/19775] [3.3 regression] sqrt(pow(x,y)) != pow(x,y*0.5)
-- What|Removed |Added Severity|normal |critical Keywords||wrong-code Known to fail||3.4.4 4.0.0 Known to work||3.3.5 Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19775
[Bug c++/19761] -Winit-self doesn't work anymore
--- Additional Comments From oliverst at online dot de 2005-02-03 10:19
---
strange...I just tried it again with this example:
extern void foo(int);
int main()
{
int i = i;
foo(i);
return i;
}
And I get only this (C and C++ front-end / -O1, -O2 and -O3):
$ gcc -Wuninitialized -Winit-self -O1 test.cpp
test.cpp: In function `int main()':
test.cpp:5: warning: 'i' might be used uninitialized in this function
Maybe it was fixed between GCC 3.4.2 and GCC 3.4.3? Or it's a target-specific
problem? I unfortunately don't have a linux GCC 3.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19761
[Bug c++/17401] [3.4/4.0 Regression] ICE with invalid pure specifier
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 10:26 --- Subject: Bug 17401 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 10:26:23 Modified files: gcc/cp : ChangeLog parser.c decl2.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: error25.C Log message: PR c++/17401 * parser.c (cp_parser_pure_specifier): Emit a specific error message with an invalid pure specifier. * decl2.c (grok_function_init): Remove. (grokfield): An initializer for a method is a always a pure specifier. PR c++/17401 * g++.dg/parse/error25.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4614&r2=1.4615 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.310&r2=1.311 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.764&r2=1.765 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4992&r2=1.4993 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/error25.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17401
[Bug c++/17401] [3.4/4.0 Regression] ICE with invalid pure specifier
--- Additional Comments From giovannibajo at libero dot it 2005-02-03 10:29 --- I have fixed the diagnostic issue as well. I don't see anything else in this PR which is worth a regression, so I'm closing it. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17401
[Bug middle-end/19775] [3.4/4.0 regression] sqrt(pow(x,y)) != pow(x,y*0.5)
-- What|Removed |Added Summary|[3.3 regression]|[3.4/4.0 regression] |sqrt(pow(x,y)) != |sqrt(pow(x,y)) != |pow(x,y*0.5)|pow(x,y*0.5) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19775
[Bug c++/19776] New: compiler crash (segmentation fault)
$ uname -a Linux localhost 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown $ g++ -v Using built-in specs. Configured with: ../configure --prefix=/usr/local/toolchain-4.0.0 --with-gcc-version-trigger=/home/syncad/gcc-4.0-20050130/gcc/version.c --enable-languages=c,c++ Thread model: posix gcc version 4.0.0 20050130 (experimental) $ g++ -g3 -ggdb3 -gstabs+ -O0 -fPIC -Wl,-O1 -trigraphs -Wall -Wno-unknown-pragmas -Wno-trigraphs -Wno-deprecated -fpermissive -fno-strict-aliasing -fPIC -fno-for-scope -fPIC -c -o xxx importwaveformdlg.cpp :1:1: warning: "__STDC_HOSTED__" redefined :1:1: warning: this is the location of the previous definition g++: -O1: linker input file unused because linking not done :1:1: warning: "__STDC_HOSTED__" redefined :1:1: warning: this is the location of the previous definition In file included from ./gridtreectrl/GridOptionCell_src/GridComboCell.h:12, from ./gridtreectrl/TreeColumn_src/GridTreeCell.h:66, from ./newt/ch/igridtreecontrol.h:10, from ./gridtreectrl/dep/acommongridtreecontrol.h:9, from ./gridtreectrl/dep/avirtualgridtreecontrol.h:9, from newt/asyncadvirtualgridtreecontrol.h:9, from newt/availablesignalsvirttreectrl.h:9, from newt/importwaveformdlg.h:11, from newt/importwaveformdlg.cpp:22: owl6/include/owl/commctrl.h:910: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ I tried to remove parts of the code which are not needed to make gcc crash but it did not go well. The code contains almost no implementation. It is almost all only declarations. Regardless of this, trying to change class declarations with forward declararions makes the crash disappear. I was able to remove something but it seems that preprocessed code must be really so long (about 160,000 lines). I do not see a way to attach the preprocessed code here. So, please, (whoever will look into this) send me an email to [EMAIL PROTECTED] so that I can send the code as attachement. Peter. -- Summary: compiler crash (segmentation fault) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter at syncad dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19776
[Bug fortran/19777] New: -fbounds-check catches non-existent bounds violation
The attached sample code fails when compiledwith bounds-check, yet there's no bounds violation. Note that it works correctly if the vector is declared with v(n) instead of v(*). - i686-pc-linux-gnu [EMAIL PROTECTED] TEMP]$ gfortran -fbounds-check -otmp2 tmp2.f90 [EMAIL PROTECTED] TEMP]$ ./tmp2 Fortran runtime error: Array reference out of bounds [EMAIL PROTECTED] TEMP]$ gfortran -v Using built-in specs. Configured with: ../gcc-4.0-20050130/configure --prefix=/usr/local/gfortran Thread model: posix gcc version 4.0.0 20050130 (experimental) -- Summary: -fbounds-check catches non-existent bounds violation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
[Bug fortran/19777] -fbounds-check catches non-existent bounds violation
--- Additional Comments From sfilippone at uniroma2 dot it 2005-02-03 10:50 --- Created an attachment (id=8133) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8133&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
[Bug tree-optimization/19778] New: Unnecessary jumps for comparisons
unsigned long le1_bit(unsigned long x) {
return x == 0 || (x & (x - 1)) == 0;
}
yields with 4.0.0 20050201:
le1_bit: clr v0
lda t0,-1(a0)
beq a0,L1
and a0,t0,t0
bne t0,L2
L1: lda v0,1
L2: ret
that is, two unnecessary jumps as compared to the completely straight-forward
translation:
le1_bit: cmpeq a0,0,t0
lda t1,-1(a0)
and a0,t1,t1
cmpeq t1,0,t1
or t0,t1,v0
ret
--
Summary: Unnecessary jumps for comparisons
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug c++/19776] compiler crash (segmentation fault)
--- Additional Comments From falk at debian dot org 2005-02-03 11:09 --- (In reply to comment #0) > I do not see a way to attach the preprocessed code here. Try here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19776 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19776
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-03 12:24 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-03 > 00:57 --- > Joel, I'm suspicious that the result you got on the branch should also be > happening on mainline; it's happening in a code section which I haven't > touched. There's a suspicious-looking difference between Arnaud's configure > output for the GCC subdir and yours: > Arnauds: > checking for .preinit_array/.init_array/.fini_array support... yes > Yours: > checking for .preinit_array/.init_array/.fini_array support... no What is this checking? Host, target? My host compiler is: bash-2.05$ type gcc gcc is /opt/gcc-40-CVS/bin/gcc bash-2.05$ type gnatmake gnatmake is /opt/gcc-40-CVS/bin/gnatmake bash-2.05$ gcc --version gcc (GCC) 4.0.0 20050113 (experimental) Same version for gnatmake. Some targets do see to fail with errors indicating different exception models. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug driver/19117] gcc -v should include target information
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 13:03 --- Subject: Bug 19117 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 13:03:26 Modified files: gcc: ChangeLog gcc.c Log message: PR driver/19117 * gcc.c (main): Include the target in -v output. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7385&r2=2.7386 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcc&r1=1.445&r2=1.446 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19117
[Bug c++/19776] compiler crash (segmentation fault)
--- Additional Comments From peter at syncad dot com 2005-02-03 13:16 --- Created an attachment (id=8134) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8134&action=view) This is the preprocessed code which leads to the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19776
[Bug driver/19117] gcc -v should include target information
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 13:46 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19117
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From amacleod at redhat dot com 2005-02-03 14:37 --- (In reply to comment #23) > We have incomming into out-of-ssa, > >x.1 = exp1 >x.2 = x.1 + exp2 >x.3 = x.2 + exp3 > > We're currently allowing TER to produce > >x.3 = exp1 + exp2 + exp3 > > What if we were to disable TER substitution when the base variable on the lhs > matches the base variable on the rhs? So in this case we'd notice x.1 and x.2 > have the same base variable and not merge. And (more importantly) so forth so > that the definitions of x.20 and x.19 aren't merged either. of course, the real issue isnt just the root variable is it? We could have TER introduce an expression with 1000 different base variables in the expression, and the problem is that we've got 1000 live now instead of something a little more sane by accumulating along the way. IN the above example, it depends on what is in exp1, exp2 and exp3 as to whether you want to avoid the subsitution. if all 3 exp's end up equating to y.6 + y.6, you probably DO want to let it happen so you end up with x.3 = y.6 + y.6 + y.6 + y.6 + y.6 + y.6 > This can probably still fall down, especially when a lot of our variables get > replaced by "ivtmp.x" and "pretmp.y", but at least we'll have some cut off > that > handles accumulation naturally. Perhaps there's some loser notion of "base > variable" we can use, like "in the same partition", or something. The partitions have been decided by the time TER runs, so we know what SSA_NAME is going to be a different variable and what isn't. all you need to do is compare var_to_partition(ssa_name) to see if they are in the same partition number. I suspect that anything easy we can do will have performance slow downs if we do it at >=-O2, but you never know :-). I suspect the better solution is to limit the number of live ranges it can introduce to something sane. I dont think that is likely to be too hard to code, the question is how quickly can it run :-) At every expression replacement point, we'd have to make a quick run through the operands and count unique partitions. Are we looking to do this at -O2 as well? I guess thats a key question. at just -Os, it might very well be sufficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug tree-optimization/19736] [4.0 Regression] ICE with type mismatch between SSA_NAME and its symbol
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 15:12 --- Fixed. thanks for your report. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19736
[Bug c++/19763] surplus -Wuninitialized warnings
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 15:14 --- Subject: Bug 19763 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 15:13:45 Modified files: gcc: ChangeLog tree-ssa.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr19736.c Log message: 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19763 * gcc.c-torture/compile/pr19736.c: New test. 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19736 * tree-ssa.c (replace_immediate_uses): Update the immediate_uses information for the new statement. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7386&r2=2.7387 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa.c.diff?cvsroot=gcc&r1=2.75&r2=2.76 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4993&r2=1.4994 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr19736.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19763
[Bug tree-optimization/19736] [4.0 Regression] ICE with type mismatch between SSA_NAME and its symbol
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 15:14 --- Subject: Bug 19736 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 15:13:45 Modified files: gcc: ChangeLog tree-ssa.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr19736.c Log message: 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19763 * gcc.c-torture/compile/pr19736.c: New test. 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19736 * tree-ssa.c (replace_immediate_uses): Update the immediate_uses information for the new statement. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7386&r2=2.7387 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa.c.diff?cvsroot=gcc&r1=2.75&r2=2.76 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4993&r2=1.4994 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr19736.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19736
[Bug middle-end/19775] [3.4/4.0 regression] sqrt(pow(x,y)) != pow(x,y*0.5) (with -ffast-math)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 15:14 --- Confirmed but you forgot the most important thing (even though you did say this on the mailing lists), the options you used to reproduce the failure. -funsafe-math-optimizations is needed to reproduce this. -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-03 15:15:00 date|| Summary|[3.4/4.0 regression]|[3.4/4.0 regression] |sqrt(pow(x,y)) != |sqrt(pow(x,y)) != |pow(x,y*0.5)|pow(x,y*0.5) (with -ffast- ||math) Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19775
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From giovannibajo at libero dot it 2005-02-03 15:15 --- > Are we looking to do this at -O2 as well? I guess thats a key question. > at just -Os, it might very well be sufficient. As stevenb noted today in IRC, the code reduction substantially comes from less spilling code being emitted, which also means that the generated code *will* run faster. I guess it's better to have it at -O2 too (until the register allocator gets fixed, but hey...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug tree-optimization/19736] [4.0 Regression] ICE with type mismatch between SSA_NAME and its symbol
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 15:16 --- Subject: Bug 19736 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 15:16:31 Modified files: gcc/testsuite : ChangeLog Log message: fix PR number in the testsuite/Changelog: 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19736 * gcc.c-torture/compile/pr19736.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4994&r2=1.4995 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19736
[Bug tree-optimization/19768] [4.0 Regression] ICE: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 15:24 --- Fixed. Thanks for your report. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
[Bug tree-optimization/19768] [4.0 Regression] ICE: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 15:26 --- Subject: Bug 19768 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-03 15:26:30 Modified files: gcc: tree-ssa-dse.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr19768.C Log message: 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19768 * g++.dg/opt/pr19768.C: New test. 2005-02-03 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/19768 * tree-ssa-dse.c (fix_phi_uses): Update the occurs in abnormal phi flag if the phi is abnormal. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dse.c.diff?cvsroot=gcc&r1=2.15&r2=2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7387&r2=2.7388 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4995&r2=1.4996 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19768.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From uros at kss-loka dot si 2005-02-03 15:40 --- (In reply to comment #21) > Uros, what exactly are you trying to show with numbers with and without > scheduling for Pentium 4? There is no scheduler description for it, so Ooops... I have mixed-up the testcases. The timings and the testcase were from PR13712. Where is that brown-paper bag of mine...? I'll retest the cases from comment #20 with correct testcase. However, I would like to show the effect of scheduler [please note that cases a) and b) are compiled with pentium classic architecture] and reg-stack interactions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug c++/19776] compiler crash (segmentation fault)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 15:44 --- Hmm, here is the story on powerpc-darwin, I can reproduce it with a full bootstrapped compiler. And I looked at the backtrace which looks very front-end dependent but it also was in the gc at the time so I don't know if this is a front-end bug or a gc bug somewhere. I am rerunning it with "--param ggc-min-expand=0 --param ggc-min-heapsize=0". Then again this might have been fixed already. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19776
[Bug middle-end/19405] 18_support/numeric_limits.cc fails on ppc-darwin (long doubles)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03 15:45 --- Fixed, I will file a new bug for the missed optimization now. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19405
[Bug middle-end/19779] New: IBM 128bit long double format is not constant foldded.
This is the new bug for PR 19405. Keeping track of that we no longer constant fold long doubles in the IBM 128bit long double format. -- Summary: IBM 128bit long double format is not constant foldded. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: middle-end 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=19779
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-03 15:51 --- FWIW, the reason this leaves a bad taste in my mouth is that I strongly believe symbol visibility should be consistent between ELF platforms. There's at least one ELF platform where resolving a function pointer to a PLT entry is an absolute no-show (MIPS binding stubs). -- What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-02-03 15:59 --- Each psABI defines how function address works. Not all of psABIs have the same treatment for function address. Function address may mean different things for different psABIs. You can't even compare function address between the x86 psABI and the mips psABI. Where does the consistency come from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From amacleod at redhat dot com 2005-02-03 16:05 --- (In reply to comment #26) > > Are we looking to do this at -O2 as well? I guess thats a key question. > > at just -Os, it might very well be sufficient. > > As stevenb noted today in IRC, the code reduction substantially comes from > less > spilling code being emitted, which also means that the generated code *will* > run faster. I guess it's better to have it at -O2 too (until the register > allocator gets fixed, but hey...) You missed my point. Sure, in the cases where we end up spilling less, its likely to run faster. But we are going to miss combine opportunites in other cases where we wouldnt have spilled in the first place. If we are going to do this at >=-O2, we're probably better off actually looking at how many live ranges we are introducing to solve the issue. If the big expression doesnt introduce too many live ranges, we might as well allow TER to continue and give the expanders a better view. Thats why TER exists in the first place. In any case, its all heuristical, so there will always be cases it doesnt work right for. If we measure SPEC or something else and the simple rootvar approach works fine, then go with it. If there are issues, then we can visit something a bit different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From uros at kss-loka dot si 2005-02-03 16:17 --- Promised timings, all on P4-3.2, 800MHz FSB: gcc296 -O3: real0m0.978s user0m0.979s sys 0m0.000s gcc296 -O3 -march=i686: real0m1.061s user0m1.029s sys 0m0.016s gcc344-pre -03 real0m0.962s user0m0.961s sys 0m0.002s gcc344-pre -03 -march=pentium4: real0m0.962s user0m0.961s sys 0m0.000s gcc-40 -O3 -march=i686: <- scheduler is enabled here! real0m0.605s user0m0.605s sys 0m0.000s gcc-40 -O3 -march=pentium4: <- scheduler disabled real0m0.599s user0m0.600s sys 0m0.000s gcc-40 -O3 -march=pentium4 -mfpmath=sse: real0m0.726s user0m0.727s sys 0m0.000s I didn't test 3.3 but I wouldn't call the results of 3.4 and 4.0 _FAR_SLOWER_ :) gcc -O3 -march=i686 -msse2 -mfpmath=sse real0m0.726s user0m0.725s sys 0m0.002s BTW: It looks there is a problem with -mfpmath=sse. I'll open another PR for this problem: "Floating point computation far slower for -mfpmath=sse" :). Steven, I guess this PR should be marked as fixed. -- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-08-01 00:24:18 |2005-02-03 16:17:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug target/19780] New: Floating point computation far slower for -mfpmath=sse
The testcase from PR 8126 runs ~20% slower when compiled with -mfpmath=sse:
--cut here--
#include
typedef float real;
int
main (int argc, char *argv[])
{
int i;
real v1x, v1y, v1z;
real v2x, v2y, v2z;
real v3x, v3y, v3z;
printf ("Start?\n");
v1x = 1.;
v1y = 0.;
v1z = 0.;
v2x = 0.;
v2y = 1.;
v2z = 0.;
for (i = 0; i < 1; i++)
{
v3x = v1y * v2z - v1z * v2y;
v3y = v1z * v2x - v1x * v2z;
v3z = v1x * v2y - v1y * v2x;
v1x = v2x;
v1y = v2y;
v1z = v2z;
v2x = v3x;
v2y = v3y;
v2z = v3z;
}
printf ("Stop!\n");
printf ("Result = %f, %f, %f\n", v3x, v3y, v3z);
return 0;
}
--cut here--
gcc -O3 -march=pentium4
real0m0.603s
user0m0.602s
sys 0m0.002s
gcc -O3 -march=pentium4 -mfpmath=sse
real0m0.726s
user0m0.727s
sys 0m0.000s
--
Summary: Floating point computation far slower for -mfpmath=sse
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
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=19780
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From uros at kss-loka dot si 2005-02-03 16:26 --- (In reply to comment #23) > BTW: It looks there is a problem with -mfpmath=sse. I'll open another PR for > this problem: "Floating point computation far slower for -mfpmath=sse" :). PR 19780 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From bangerth at dealii dot org 2005-02-03 16:29 --- Convincing evidence has been provided. I'll close the PR. W. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug target/19780] Floating point computation far slower for -mfpmath=sse
--- Additional Comments From uros at kss-loka dot si 2005-02-03 16:40 --- First thing to see is this: ... mulss %xmm7, %xmm1 movss -12(%ebp), %xmm0 mulss %xmm4, %xmm0 subss %xmm0, %xmm1 movss -12(%ebp), %xmm0 mulss %xmm5, %xmm0 mulss %xmm6, %xmm3 ... Memory access is expensive, but in -mfpmath=387 case we have equivalent code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug libstdc++/19781] New: testsuite_hooks.cc doesn't test for mkfifo
testsuite/testsuite_hooks.cc is compiled as part of the libstdc++ build itself,
rather than just for testing. I have a build problem there that therefore stops
the whole gcc build
On line 233 ish there is:
int
try_mkfifo (const char* filename, mode_t mode)
{
#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo. */
exit(0);
#else
return mkfifo(filename, mode);
#endif
}
However I am using an OS that does not have mkfifo, and is not newlib-based
(various system headers copied into the appropriate sys-include location). This
test should instead be done by autoconf, probably by just
AC_CHECK_FUNCS(mkfifo) somewhere, but I'm not sure exactly what's best in a
cross-compiled situation.
I can prepare a patch against gcc 3.4.3 if I have a little guidance, or it may
be easier just to fix by someone more knowledgable in this area.
--
Summary: testsuite_hooks.cc doesn't test for mkfifo
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik 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: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-03 16:49 --- To the reporter: in this case you probably want __attribute__ ((leafify)), just in case, though you are right in expecting the compiler to inline it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-02-03 17:32 --- Subject: Re: [4.0 Regression] threefold performance loss, not inlining as much bonzini at gcc dot gnu dot org wrote: > To the reporter: in this case you probably want __attribute__ ((leafify)), > just > in case, though you are right in expecting the compiler to inline it. But of course attribute leafify is not available without patching your gcc sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
const char *& and std::map<_K, _V>::iterator& : what's wrong?
Hi!
First, thanks to "Giovanni Bajo" <[EMAIL PROTECTED]> for help.
Consider simple C++ program:
-
#include
template
void func_map(typename std::map<_K, _V>::iterator& root) {
}
int main() {
std::map mymap;
func_map(mymap.begin());
}
-
Notice '&' in the line:
void func_map(typename std::map<_K, _V>::iterator& root) {
Just because this '&' program won't compile:
(gcc 3.4.1 log):
--
testref.cpp: In function `int main()':
testref.cpp:18: error: invalid initialization of non-const reference of type
'std::_Rb_tree_iterator >&' from a temporary of
type 'std::_Rb_tree_iterator >'
testref.cpp:9: error: in passing argument 1 of `void func_map(typename
std::map<_K, _V, std::less<_Key>, std::allocator >
>::iterator&) [with _K = int, _V = int]'
---
Why does std::_Rb_tree_iterator >& appear?
Just remove '&' from typename std::map<_K, _V>::iterator& root
- no warnings, no errors.
Is it gcc bug or ISO C++ violation?
Also, much more simple example won't work:
--
void func(const char *& p) { // Another developer puts '&' here.
}
int main() {
char *ptr = "dsadas";
// I can't write 'const char *' because of program's mutable logic.
// This logic intoduced by another developer.
func(ptr);
}
---
And, just remove '&' and all is ok.
NOTE. MSVC6 compiles all code above.
[Bug middle-end/19775] [3.4/4.0 regression] sqrt(pow(x,y)) != pow(x,y*0.5) (with -ffast-math)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-03 17:47 --- Subject: Bug 19775 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-03 17:47:33 Modified files: gcc: ChangeLog builtins.c gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: builtins-10.c Added files: gcc/testsuite/gcc.dg: builtins-47.c Log message: PR middle-end/19775 * builtins.c (fold_builtin_sqrt): Transform sqrt(pow(x,y)) to pow(fabs(x),y*0.5), not pow(x,y*0.5). * gcc.dg/builtins-10.c: Disable test for invalid transformation and one test we no longer optimize. * gcc.dg/builtins-47.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.791&r2=2.2326.2.792 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.275.2.5&r2=1.275.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.355&r2=1.3389.2.356 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/builtins-47.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/builtins-10.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1&r2=1.1.22.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19775
