[Bug target/19704] ICE for tail call of regparm 3 and dllimport
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19704
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31 09:00 --- Subject: Re: [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level Hello, new timings are here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html Actually typecode.cc went to ~9% regression for -O1, please read this report for more information why. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug other/19696] gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31 09:02 --- Subject: Bug 19696 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-31 09:02:35 Modified files: gcc: ChangeLog optabs.c Log message: PR 19696 * optabs.c (expand_copysign_absneg): New. (expand_copysign_bit): Split out from ... (expand_copysign): ... here. Use expand_copysign_absneg. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7337&r2=2.7338 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcc&r1=1.256&r2=1.257 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19696
[Bug target/19672] Performance regression in simple loop code
--- Additional Comments From stephan dot bergmann at sun dot com 2005-01-31 09:09 --- "I think you can get all the speed back by supplying -mbranch-cost=1 but I could be wrong." No, adding -mbranch-cost=1 leads to only a very minor performance improvement. "Can you give the output of "gcc -v" for both GCC's?" 3.4.3> gcc -v Reading specs from /export/home/sb93797/gcc-3.4.3-inst/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/export/home/sb93797/gcc-3.4.3-inst Thread model: posix gcc version 3.4.3 3.2.2> gcc -v Reading specs from /so/env/gcc_3.2.2_linux_libc2.20/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs Configured with: /export/home/obo/gcc-3.2.2/configure --prefix=/net/grande.germany/develop6/update/dev/gcc_3.2.2_linux_libc2.20 --with-as=/net/grande.germany/develop6/update/dev/gcc_3.2.2_linux_libc2.20/bin/as --with-ld=/net/grande.germany/develop6/update/dev/gcc_3.2.2_linux_libc2.20/bin/ld --enable-languages=c,c++ Thread model: posix gcc version 3.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-01-31 09:21 --- Subject: Re: gnat tools not buildable cross > Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would > you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC. There must be a simpler way to fix this regression. I am not even convinced that this change would fix this particular bug anyway, so we first need this info before proceeding. Such major addition is not suitable for stage 3 in my opinion (but very welcome for stage 1), we want a much more localized change, which is certainly possible here. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31 09:31 --- Hello, new timings MICO ORB sources are here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug c/19333] [4.0 Regression] C front end accepts arrays of incomplete types
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 09:54 --- Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/ -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug c++/19620] exception not caught when passing through C code
--- Additional Comments From jkanze at cheuvreux dot com 2005-01-31 09:55 --- Subject: Re: exception not caught when passing through C code > This is documented somewhere in the docs, I think. If you mix C > codes with C++ and exceptions are raised (through callbacks) and > you need exceptions to smoothly travel across language > boundaries, you need to compile the C code with -fexceptions. The problem is that you don't always have the sources for the C code. Most of the time, it is in some third party library for which you only have the .h's and the .a (or .so). (And the third party library has likely been compiled with Sun's cc, not gcc.) I'll admit that I don't understand the problem, at least on Sparc. There is an ABI which defines what the C stack looks like; the C++ stack is, in fact, identical. Walking back the stack is trivial. The only thing you need the tables for is for finding destructor or handler code. So you won't find them in the C code which doesn't have the tables; that's no problem, because I'm pretty sure that the C code doesn't have any destructors, nor any exception handlers. Is there something linked with portability which precludes this approach. (I know that the stack walkback code is NOT portable. But I would have thought that this was true with or without the tables.) -- James KanzeGABI Software mailto: [EMAIL PROTECTED] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19620
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-31 10:32 --- Ok, now I see the issue clearly: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00114.html In particular: "I did not attempt to fix all of the V3 headers; I'm only concerned with libsupc++ at the moment. However, similar changes should probably be made throughout V3. Otherwise, linkage will be wrong if people #include (say) with a non-default symbol visibility." Will fix this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/19620] exception not caught when passing through C code
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-31 10:54 --- > I'll admit that I don't understand the problem, at least on > Sparc. There is an ABI which defines what the C stack looks > like; the C++ stack is, in fact, identical. Walking back the > stack is trivial. The only thing you need the tables for is for > finding destructor or handler code. This indeed may be true on SPARC. > So you won't find them in the C code which doesn't have the tables; that's no > problem, because I'm pretty sure that the C code doesn't have any > destructors, nor any exception handlers. Sure, but GCC nevertheless needs unwind info describing that there is no table and how to further unwind. > Is there something linked with portability which precludes this > approach. (I know that the stack walkback code is NOT portable. > But I would have thought that this was true with or without the > tables.) The exception propagation mechanism is generic and doesn't special-case SPARC at the moment. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19620
[Bug target/19714] temporary not eliminated in composite _mm_set1_epi32
--- Additional Comments From uros at kss-loka dot si 2005-01-31 11:14
---
This is .t69.final_cleanup:
;; Function long long int __vector__ not_eliminated_bis(const int&)
(_Z18not_eliminated_bisRKi)
long long int __vector__ not_eliminated_bis(const int&) (i)
{
int __q0;
:
__q0 = *i;
return (__m128i) {__q0, __q0, __q0, __q0};
}
;; Function int main() (main)
int main() ()
{
:
return 0;
}
;; Function long long int __vector__ eliminated(int) (_Z10eliminatedi)
long long int __vector__ eliminated(int) (i)
{
:
return (__m128i) {i, i, i, i};
}
;; Function long long int __vector__ not_eliminated(const int*)
(_Z14not_eliminatedPKi)
long long int __vector__ not_eliminated(const int*) (i)
{
int __q0;
:
__q0 = *i;
return (__m128i) {__q0, __q0, __q0, __q0};
}
We have the assignment __q0 = *i in every function where we expect this
temporary to be eliminated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714
[Bug tree-optimization/17454] [4.0 Regression] ICE with --enable-checking=fold
--- Additional Comments From micis at gmx dot de 2005-01-31 12:06 --- I have rechecked it at x86_64. It occurs only with configure/make bootstrap, not with configure make. Actual error is: stage1/xgcc -Bstage1/ -B/usr/local/gcc40c/x86_64-unknown-linux-gnu/bin/ -c - g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- definition -Werror-DHAVE_CONFIG_H-I. -I. -I../../gcc40/gcc - I../../gcc40/gcc/. -I../../gcc40/gcc/../include - I../../gcc40/gcc/../libcpp/include ../../gcc40/gcc/dbxout.c -o dbxout.o ../../gcc40/gcc/dbxout.c: In function 'dbxout_int': ../../gcc40/gcc/dbxout.c:429: internal compiler error: fold check: original tree changed by fold Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [dbxout.o] Error 1 make[2]: Leaving directory `/home/cie019/gcc40c/obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/cie019/gcc40c/obj/gcc' make: *** [bootstrap] Error 2 I will check it on ppc later Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17454
[Bug c/19720] New: missing braces around initializer
while compiling gcc-3.4.3 with itself(compiled by gcc-2.95), got these error: --- In file included from ../../gcc-3.4.3/gcc/unwind-dw2-fde-glibc.c:59: ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: warning: missing braces around initializer ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: warning: (near initialization for `object_mutex.__data') ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: error: `__LOCK_INITIALIZER' undeclaredhere (not in a function) ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: error: initializer element is not constant ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: error: (near initialization for `object_mutex.__data.__nusers') ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: warning: missing initializer ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: warning: (near initialization for `object_mutex.__data.__nusers') ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: error: initializer element is not constant ../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: error: (near initialization for `object_mutex.__data') make[3]: *** [libgcc/./unwind-dw2-fde-glibc.o] Error 1 make[3]: Leaving directory `/src/gcc-build2/gcc' make[2]: *** [libgcc.a] Error 2 make[2]: Leaving directory `/src/gcc-build2/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/src/gcc-build2/gcc' make: *** [bootstrap] Error 2 --- on a debian woody-3.0-r2 system, with: kernel-2.6.10 glibc-2.3.3 (--prefix=/usr) gcc-3.4.3 (--prefix=/usr/local) -- Summary: missing braces around initializer Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ca50015 at yahoo dot com 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=19720
[Bug c/19720] missing braces around initializer
--- Additional Comments From ca50015 at yahoo dot com 2005-01-31 12:19 --- can't find the string "__LOCK_INITIALIZER" through gcc source files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches
This is a meta bug for tracking what CSE still does and other passes do not catch. After some SPEC runs with CSE disabled completely or with at least CSE path following disabled, it seems that we are very close to the point where cse.c can be cleaned up significantly. Please hang any known missed-optimization bugs involving cse.c from this meta-bug. -- Summary: [meta-bug] optimizations that CSE still catches Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: meta-bug Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steven at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added CC||kazu at cs dot umass dot ||edu, pinskia at gcc dot gnu ||dot org, dnovillo at gcc dot ||gnu dot org, hubicka at gcc ||dot gnu dot org Summary|[meta-bug] optimizations|[meta-bug] optimizations |that CSE still catches |that CSE still catches http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 12:39 --- To get something started, I have done SPECint and SPECfp runs on AMD64 with CVS HEAD 20050130, unmodified vs. a cse.c with path following disabled (by setting the max-cse-path-length to 1). The overall scores go *up* (!!!) with that change, but some individual benchmarks regress. Still this is a lot better than half a year ago, when terminating CSE would cause an overall regression of more than 10%. Diego Novillo also had his SPEC tester on i686 run, with CSE completely disabled, and there, too, the overall performance drop was not as large as one would maybe have expected. Note that completely disabling is a step further than setting the max-cse-path-length to 1. The latter effectively makes CSE a purely local pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added BugsThisDependsOn||19659 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 12:42 --- Created an attachment (id=8112) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8112&action=view) gcov coverage testing of CVS HEAD 20050131 on AMD64 This is the coverage data of cse.c for 517 preprocessed C files from the GCC sources (517 files, including all components of cc1). Note especially how ineffective fold_rtx is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/19522] Fix GCC so that a nonlocal label won't appear after local labels.
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 12:55 --- Now tree_verify_flow_info verifies that a nonlocal label does not appear in the middle of a seuqnece of labels. http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01383.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug other/19722] New: gcc 3.2.3 installation problem on x86
I am trying to install gcc 3.2.3 on an opteron machine (x86, 64 bit, redhat enterprise Linux version 3.0). I am facing the a problem. What i did is ... configured using the following command... srcdir/configure --prefix=destdir/gcc --enable-threads Then in the object dir (objdir) did the make make -w |& tee -i log Ended-up with the following error in the log file. objdir/gcc-3.2.3/gcc/xgcc -Bobjdir/gcc-3.2.3/gcc/ -Bdestdir/gcc/x86_64-unknown- linux-gnu/bin/ -Bdestdir/gcc/x86_64-unknown-linux-gnu/lib/ -isystem destdir/gcc/x86_64-unknown-linux-gnu/include -S tmp-dum.c cc1: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [s-under] Error 1 make[1]: Leaving directory `objdir/gcc-3.2.3/gcc' make: *** [all-gcc] Error 2 make: Leaving directory `objdir/gcc-3.2.3' -- Thanks & Regards, Sitaram. -- Summary: gcc 3.2.3 installation problem on x86 Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sitaram dot banda at gmail dot com CC: gcc-bugs at gcc dot gnu dot org,sitaram dot banda at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug tree-optimization/18848] PRE creates "a_1 = 0 * 4" but does not fold it.
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 13:22 --- This has been fixed with Daniel Berlin's recent check-in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18848
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 13:30 --- Is this still a problem for you with more recent releases of GCC? I don't think anyone is still interested in providing patches for GCC 3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-31 13:40 --- > Is this still a problem for you with more recent releases of GCC? I don't > think > anyone is still interested in providing patches for GCC 3.2. Moreover I'm not sure the FSF 3.2.x compiler is really reliable on AMD64. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug tree-optimization/19723] New: [4.0 Regression] A side effect is missed in 0 % a++.
Consider:
int
foo (int a)
{
int x = 0 % a++;
return a;
}
Here is what I get:
foo (a)
{
:
return a;
}
--
Summary: [4.0 Regression] A side effect is missed in 0 % a++.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug tree-optimization/19643] "0 % variable" isn't optimized to 0 at tree level
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 13:42 --- This has been fixed, but the fix isn't complete. See PR 19723. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug rtl-optimization/12845] [3.4/4.0 Regression] missed jump optimization
-- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12845
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From bangerth at dealii dot org 2005-01-31 14:02 --- gcc 3.2.x was definitely not stable on opteron. As far as I remember, opteron support was developed by SuSE on the hammer branch and by redhat on top of their 3.2.x based compiler. I believe that both folded their changes back into the 3.3.x series, but 3.2.3 is certainly not a good idea to use on that system. Besides that, we stopped support for 3.2.3. Please test with a newer release, and if there are still problems, open a new PR. Thanks Wolfgang -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:03
---
The first two cases are optimized as expected.
The third one is wrong. Here is mostly likely what Andrew Pinski meant to say.
void
t2 ()
{
int i;
int x;
for (i = 0; i < 1; i++)
{
int t = (
{
int j = i;
if (j < 1)
j = 1;
else
j = 0;
j;
}
);
f (t);
}
}
which is again optimized as optimized.
--
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 14:14 --- Yes, and i'm not asking for a GPR->SSE transfer. What i'm asking is why gcc feels the urge to copy that memory reference to the stack before fooling around with it. The full sequence is: 401298: 8b 42 28mov0x28(%edx),%eax 40129b: 89 44 24 1c mov%eax,0x1c(%esp) 40129f: 66 0f 6e 64 24 1c movd 0x1c(%esp),%xmm4 4012a5: 66 0f 70 cc 00 pshufd $0x0,%xmm4,%xmm1 whereas ICC does: 40241d: 66 0f 6e 44 ca 28 movd 0x28(%edx,%ecx,8),%xmm0 40242c: 66 0f 70 c0 00 pshufd $0x0,%xmm0,%xmm0 I've opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug middle-end/19702] suboptimal multiple branch comparison code produced
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:28 --- *** This bug has been marked as a duplicate of 14483 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19702
[Bug rtl-optimization/14483] More aggressive compare insn elimination
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:28 --- *** Bug 19702 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14483
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31 14:38 --- This is with the 20050130 snapshot on ia64-unknown-linux-gnu, -O3 and with flag_complex_divide_method = 1. The files slasy2.f and dlasy2.f are compiled with -O0, to get around PR 18977. cgd.out: CGV drivers: 61 out of 1092 tests failed to pass the threshold csep.out: CST:2 out of 4662 tests failed to pass the threshold csep.out: CST drivers: 1 out of 11664 tests failed to pass the threshold ded.out: DES:2 out of 3264 tests failed to pass the threshold ded.out: DSX:2 out of 3494 tests failed to pass the threshold dgd.out: DXV drivers:200 out of 5000 tests failed to pass the threshold sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold ssep.out: SST:2 out of 4662 tests failed to pass the threshold ssep.out: SST drivers: 1 out of 14256 tests failed to pass the threshold zgd.out: ZGV drivers: 61 out of 1092 tests failed to pass the threshold zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold This is looking pretty good, on the whole. The DES and DSX failures are a bit suspect: N=5, IWK= 1, seed= 100,2082, 33, 613, type 17, test( 7)= 0.450E+16 DDRVES: DGEES1 returned INFO= 6. N= 5, JTYPE=17, ISEED=( 100, 2082, 33, 613) N=5, IWK= 2, seed= 100,2082, 33, 613, type 17, test( 7)= 0.450E+16 DES:2 out of 3264 tests failed to pass the threshold *** Error code from DGEES =6 DGET24: DGEESX1 returned INFO= 6. N= 5, JTYPE=17, ISEED=( 100, 2082, 33, 613) N=5, IWK= 2, seed= 100,2082, 33, 613, type 17, test( 7)= 0.450E+16 DSX:2 out of 3494 tests failed to pass the threshold The condition numbers are quite high. There may or may not be an optimizer bug hidden there. I'll look around if I can isolate anything, and open a separate PR then. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug target/19720] missing braces around initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 14:41 --- Could this be a glibc bug? -- What|Removed |Added Component|c |target Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 14:44 --- Confirmed via Roger on the mailing list. -- What|Removed |Added CC||law at gcc dot gnu dot org Severity|normal |critical Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-31 14:44:36 date|| Target Milestone|--- |4.0.0 Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug java/9157] SEGV on bad java source
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-31 14:45 --- Proposed patch here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00245.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9157
[Bug tree-optimization/14797] [tree-ssa] propagate constants back to PHI
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:46
---
Seems like what I feared in comment #2 is going on.
Specifically, for the original test case, I get:
foo (a)
{
_Bool D.1130;
_Bool D.1129;
int b;
int D.1120;
:
D.1129_5 = a_2 == 0;
D.1130_6 = !D.1129_5;
b_1 = (int) D.1130_6;
D.1120_3 = b_1 + 1;
return D.1120_3;
}
I don't know if it's correct to say PHI-OPT is run too early,
but at least it is blocking us to obtain:
# b_1 = PHI <2(0), 1(1)>;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14797
[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 14:46 --- No, the first one is not even optimizated on the mainline on ppc: cmpw cr7,r30,r28 crnot 30,29 mfcr r3 rlwinm r3,r3,31,1 bl L_f$stub -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341
[Bug c++/19474] wrong linkage of extern "C" variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 14:58 --- Actually the code is invalid, see PR 6548 which this is a dup of. *** This bug has been marked as a duplicate of 6548 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/6548] Incorrect mangling for extern C and namespace
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 14:58 --- *** Bug 19474 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sstrasser at systemhaus- ||gruppe dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6548
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 15:04 --- gcc CVS mainline (2004-02-02 20:20 GMT) bootstraped using recent 4.0 accept option "-finput-charset=ISO8859-1" without error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug c/19724] New: ICE when building a m68hc11 cross-compiler on ia64
I am unable to build a m68hc11 cross-compiler on 64-bit architectures. xgcc
generates an internal compiler error during the build of libgcc2.
Here is a reduced testcase:
typedef struct
{
char a;
int b;
} foo;
void ice()
{
int c;
foo * bar;
// one of the two following instructions causes ICE
bar->b = (c << 7L);
bar->b = (c | 1);
}
and the output error:
fp-bit.c: In function `ice':
fp-bit.c:15: error: insn does not satisfy its constraints:
(insn 13 12 14 0 0x202dc720 (parallel [
(set (mem/s/j:SI (plus:HI (mem:HI (plus:HI (reg/f:HI 9 *_.frame)
(const_int 7 [0x7])) [0 S2 A8])
(const_int 1 [0x1])) [0 .b+0 S4 A8])
(reg:SI 0 x [54]))
(clobber (scratch:HI))
]) 20 {movsi_internal} (nil)
(nil))
fp-bit.c:15: internal compiler error: in final_scan_insn, at final.c:2722
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Please note that if the a and b declarations are swapped, the source is built
without problem. I also tested this code on other 64-bit architectures (amd64
and alpha) and the problem is not present.
--
Summary: ICE when building a m68hc11 cross-compiler on ia64
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: ciceron at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: m68hc11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19720] missing braces around initializer
--- Additional Comments From schwab at suse dot de 2005-01-31 15:08 --- Most likely careless mixing of NPTL and Linuxthreads headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug target/19720] missing braces around initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 15:09 --- This looks more likel a glibc bug, could you attach the preprocessed source? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 15:14 --- Are you sure that this is not a IA64 bug? Can you check the cross compiler compiled at -O0 since this sounds like a IA64 bug, also try with a newer ia64 compiler. -- What|Removed |Added Component|c |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-31 15:14:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug other/19717] -fdump-rtl-cse2 does not work as documented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 15:18 --- Confirmed, werid I think .cse should be renamed to cse1 and then cse2 might work correct or something like that. There might have been a report of this to the mailing lists before. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|other Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-31 15:18:46 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19717
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31 15:23 --- SPEC comparisons for i686 before/after kazu's patch to completely disable CSE. The 20050127 compiler has CSE enabled. The 20050129 compiler has CSE disabled. Compile times for SPECint were reduced by 9%. Compile times for SPECfp were reduced by 7.1%. Bootstrap times were reduced by 4.5% Comparison between 20050127/spec-20050127.stats and 20050129/spec-20050129.stats (base) Compiler used in 20050127/spec-20050127.stats (Before) Compiler: gcc version 4.0.0 20050127 (experimental) Base flags: -O2 -march=i686 Peak flags: -O3 -march=i686 Processor: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.264 Mhz) Memory: 1034472 kB Cache: 512 KB Compiler used in 20050129/spec-20050129.stats (After) Compiler: gcc version 4.0.0 20050129 (experimental) Base flags: -O2 -march=i686 Peak flags: -O3 -march=i686 Processor: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.264 Mhz) Memory: 1034472 kB Cache: 512 KB SPECint results for base Benchmark Before After % diff 164.gzip 650.42 578.34 - 11.08% 175.vpr 421.04 418.82 - 0.53% 176.gcc 717.60 710.60 - 0.98% 181.mcf 426.30 426.49 + 0.05% 186.crafty 635.60 632.86 - 0.43% 197.parser 546.62 563.78 + 3.14% 252.eon 541.23 566.44 + 4.66% 253.perlbmk 704.34 685.23 - 2.71% 254.gap 741.52 708.46 - 4.46% 255.vortex 822.37 823.91 + 0.19% 256.bzip2 524.96 524.44 - 0.10% 300.twolf 544.79 552.95 + 1.50% mean 594.14 588.36 - 0.97% SPECfp result for base Benchmark Before After % diff 168.wupwise 579.39 626.80 + 8.18% 171.swim 501.51 490.96 - 2.10% 172.mgrid 372.63 374.65 + 0.54% 173.applu 557.58 529.18 - 5.09% 177.mesa 417.03 412.20 - 1.16% 178.galgel 485.88 482.41 - 0.71% 179.art 207.13 205.69 - 0.70% 183.equake 820.26 797.45 - 2.78% 187.facerec 346.83 337.74 - 2.62% 188.ammp 343.35 333.60 - 2.84% 189.lucas 498.16 505.99 + 1.57% 191.fma3d 465.00 433.92 - 6.68% 200.sixtrack 383.56 371.22 - 3.22% 301.apsi 422.75 423.89 + 0.27% mean 437.11 431.45 - 1.29% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:23 --- 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-01-29 > 22:19 --- > >>You may try adding a gnattools directory, whose makefile and configury is > > based > >>on libada's, but which is a host module rather than a target module. > > > Correct (dammit). :-) > > I've already done this on the libada-gnattools-branch, > but I've also done some other things there, which wouldn't be suitable for > stage 3. Please try a snapshot of the libada-gnattools-branch from... hmm, > let's see... December 1, 2004. Where are these snapshots? Or exactly how do you want it checked out from CVS. > If it works correctly (and I know it works correctly for native tools), > it's safe enough to merge to mainline even in stage 3. I would have done so > already, but without a bug report, it wasn't stage-3-suitable. There is now a bug report against 4.x and there was at least a lot of whining for 3.3 and 3.4. :) > If it doesn't, come back to me; I expect that there's some incremental change > on top of it which should sort out any remaining problems. Great. Point me in the right direction and I will be happy to test. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:24 --- Subject: Re: gnat tools not buildable cross charlet at adacore dot com wrote: > --- Additional Comments From charlet at adacore dot com 2005-01-31 09:21 > --- > Subject: Re: gnat tools not buildable cross > > >>Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would >>you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC. If he can prepare a patch vs 4.0 CVS, I am willing to test it. > There must be a simpler way to fix this regression. I am not even convinced > that this change would fix this particular bug anyway, so we first need this > info before proceeding. Agreed. If it doesn't work on the libada branch, there there is no fix at hand. Even if it does, then a patch against 4.0 would have to be evaluated. > Such major addition is not suitable for stage 3 in my opinion (but very > welcome for stage 1), we want a much more localized change, which is certainly > possible here. That's what the RM is for. Let's get a solution first and then see if it meets the criteria. No point saying it doesn't without knowing. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 15:25 --- Subject: Re: Missed comparision optimization (jump threading related) Hi Andrew, > No, the first one is not even optimizated on the mainline on ppc: > cmpw cr7,r30,r28 > crnot 30,29 > mfcr r3 > rlwinm r3,r3,31,1 > bl L_f$stub Could you post your tree dump? This PR is supposed to be about tree optimization. If that is not true on PPC, you might want to change this to rtl-optimization or something more appropriate. As far as I can tell, tree dumps look OK for all test cases (with the third one repaired). Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31 15:26 --- Similarly for em64t. Build times for SPECint were reduced by 9.2%. Build times for SPECfp were reduced by 7.5%. Compiler bootstrap times were reduced by 4.4%. Comparison between 20050127/spec-20050127.stats and 20050130/spec-20050130.stats (base) Compiler used in 20050127/spec-20050127.stats (Before) Compiler: gcc version 4.0.0 20050127 (experimental) Base flags: -O2 -march=nocona Peak flags: -O3 -march=nocona Processor: Genuine Intel(R) CPU 2.40GHz (1866.740 Mhz) Memory: 4064772 kB Cache: 1024 KB Compiler used in 20050130/spec-20050130.stats (After) Compiler: gcc version 4.0.0 20050130 (experimental) Base flags: -O2 -march=nocona Peak flags: -O3 -march=nocona Processor: Genuine Intel(R) CPU 2.40GHz (1866.740 Mhz) Memory: 4064772 kB Cache: 1024 KB SPECint results for base Benchmark Before After % diff 164.gzip 508.55 482.96 - 5.03% 175.vpr 443.91 445.11 + 0.27% 176.gcc 760.30 762.51 + 0.29% 181.mcf 397.27 397.01 - 0.07% 186.crafty 768.76 745.77 - 2.99% 197.parser 458.55 458.83 + 0.06% 252.eon 0.000.00 INF 253.perlbmk 758.73 767.23 + 1.12% 254.gap 836.44 834.91 - 0.18% 255.vortex 0.00 850.80 INF 256.bzip2 557.58 557.19 - 0.07% 300.twolf 576.46 557.28 - 3.33% mean 587.55 602.07 + 2.47% SPECfp result for base Benchmark Before After % diff 168.wupwise 0.000.00 INF 171.swim 0.000.00 INF 172.mgrid 0.000.00 INF 173.applu 0.000.00 INF 177.mesa 767.75 765.15 - 0.34% 178.galgel 0.000.00 INF 179.art 735.31 741.52 + 0.84% 183.equake 1043.34 1007.83 - 3.40% 187.facerec 0.000.00 INF 188.ammp 558.49 536.86 - 3.87% 189.lucas 0.000.00 INF 191.fma3d 0.000.00 INF 200.sixtrack 0.000.00 INF 301.apsi 0.000.00 INF mean 757.33 744.36 - 1.71% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 15:33 --- :; f (i <= ); D.1141 = (unsigned int) i + 1; i = (int) D.1141; if (D.1141 != 1) goto ; else goto ; But note on x86 I get the same and the extra compare: .L2: xorl%eax, %eax cmpl$, %ebx <--- here setle %al movl%eax, (%esp) callf leal1(%ebx), %eax cmpl$1, %eax movl%eax, %ebx jne .L2 I have no idea what is going wrong. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341
[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 15:42 --- On my x86 machine, I get f (1). On Andrew's powerpc, he gets f (i < 100) regardless of whether he is targetting x86 or powerpc. So it might be the case that the host matters. How strange!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 15:47
---
Subject: Re: ICE when building a m68hc11 cross-compiler
on ia64
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
> 15:14 ---
> Are you sure that this is not a IA64 bug?
> Can you check the cross compiler compiled at -O0 since this sounds like a
> IA64 bug, also try with a
> newer ia64 compiler.
The problem is still present when the cross compiler is compiled at -O0.
I tried to build it with gcc 2.96, 3.2.3 and 3.3.5. I currently don't
have access to gcc 3.4 on an ia64 box.
I also tried to run gcc with "-da", which gives me a lot files, with a
content that I don't understand. I have done the same on an i386 arch,
and there is some differences:
---
ia64, fp-bit.c.00.rtl
;; Function ice
(note 1 0 2 ("fp-bit.c") 8)
(note 2 1 3 NOTE_INSN_DELETED)
(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
(note 5 4 6 0x202dc720 NOTE_INSN_BLOCK_BEG)
(note 6 5 7 NOTE_INSN_DELETED)
(note 7 6 8 ("fp-bit.c") 9)
(note 8 7 9 ("fp-bit.c") 10)
(note 9 8 10 ("fp-bit.c") 13)
(insn 10 9 11 (nil) (set (reg/f:HI 53)
(mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars)
(const_int 4 [0x4])) [0 bar+0 S2 A16])) -1 (nil)
(nil))
(insn 11 10 12 (nil) (parallel [
(set (reg:SI 54)
(mem/f:SI (reg/f:HI 49 virtual-stack-vars) [0 c+0 S4 A32]))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(insn 12 11 13 (nil) (parallel [
(set (reg:SI 55)
(ior:SI (reg:SI 54)
(const_int 1 [0x1])))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(insn 13 12 14 (nil) (parallel [
(set (mem/s/j:SI (plus:HI (reg/f:HI 53)
(const_int 1 [0x1])) [0 .b+0 S4 A8])
(reg:SI 55))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(note 14 13 15 0x202dc720 NOTE_INSN_BLOCK_END)
(note 15 14 16 NOTE_INSN_FUNCTION_END)
(note 16 15 17 ("fp-bit.c") 14)
(code_label 17 16 0 1 "" [0 uses])
---
same file on i386:
;; Function ice
(note 1 0 2 ("fp-bit.i") 8)
(note 2 1 3 NOTE_INSN_DELETED)
(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
(note 4 3 5 NOTE_INSN_DELETED)
(note 5 4 6 0xb7cc62c0 NOTE_INSN_BLOCK_BEG)
(note 6 5 7 NOTE_INSN_DELETED)
(note 7 6 8 ("fp-bit.i") 9)
(note 8 7 9 ("fp-bit.i") 10)
(note 9 8 10 ("fp-bit.i") 13)
(insn 10 9 11 (nil) (set (reg/f:HI 53)
(mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars)
(const_int 4 [0x4])) [0 bar+0 S2 A16])) -1 (nil)
(nil))
(insn 11 10 12 (nil) (parallel [
(set (reg:SI 54)
(mem/f:SI (reg/f:HI 49 virtual-stack-vars) [0 c+0 S4 A32]))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(insn 12 11 13 (nil) (parallel [
(set (reg:SI 55)
(ior:SI (reg:SI 54)
(const_int 1 [0x1])))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(insn 13 12 14 (nil) (parallel [
(set (mem/s/j:SI (plus:HI (reg/f:HI 53)
(const_int 1 [0x1])) [0 .b+0 S4 A8])
(reg:SI 55))
(clobber (scratch:HI))
]) -1 (nil)
(nil))
(note 14 13 15 0xb7cc62c0 NOTE_INSN_BLOCK_END)
(note 15 14 16 NOTE_INSN_FUNCTION_END)
(note 16 15 17 ("fp-bit.i") 14)
(code_label 17 16 0 1 "" [0 uses])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19720] missing braces around initializer
--- Additional Comments From schwab at suse dot de 2005-01-31 15:51 --- Not a glibc bug, rather a packaging bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug target/17209] ld-collate.s: Error: bad immediate value for offset (4096)
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31 15:55 --- This is indeed a duplicate of PR16201 *** This bug has been marked as a duplicate of 16201 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17209
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-31 15:56 --- > Such major addition is not suitable for stage 3 in my opinion (but very > welcome for stage 1), we want a much more localized change, which is certainly > possible here. I don't think so. When you get into the libada directory, CC="$(CC_FOR_TARGET)" and all hope is lost of having the tools work in a cross configuration. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug target/16201] Assembler messages:Error: bad immediate value for offset (4116)
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31 15:56 --- *** Bug 17209 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16201
[Bug target/16201] Assembler messages:Error: bad immediate value for offset (4116)
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31 15:59 --- The problem is the arith_adjacent_mem pattern, which is sometimes expanding to more than three instructions if the addressed objects are in the stack frame. Patch in testing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-31 15:59:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16201
[Bug c++/19725] New: missing std::wstring support
I want to compile c++ source that uses std::wstring but std::wstring is
undeclared. So I greped around an found that the specialization in stringfwd.h
needs to declare _GLIBCXX_USE_WCHAR_T. After this define, the compiler prints
out many errors about missing declarations to some w-functions.
The following source should be compiled:
#include
#include
using namespace std;
int main()
{
wstring ws( L"TEST WIDE CHARACTER STRING\n" );
printf( "%S\n", ws.c_str() );
return 0;
}
END_OF_SOURCE
I'm using gcc-3.4.3 with gcc-3.4.3-branch-update-20050110.patch.
# gcc -v
Reading specs from /usr/local/lib/gcc/hppa64-hp-hpux11.11/3.4.4/specs
Configured with: /soft/gnu/tmp/gcc-3.4.3/configure --prefix=/usr/local
--without-libgcj --enable-languages=c,objc,c++ --with-ld=/usr/local/bin/ld
--with-as=/usr/local/bin/as
Thread model: single
gcc version 3.4.4 20050111 (prerelease)
# /usr/local/bin/ld -v
GNU ld version 2.14 20030612
I have tried to compile the same code with the gcc-3.4.3 build by the HP-UX
Porting Centre but it fails with the same behavior.
Before that I tried the same code with gcc-3.1. It fails with the same behavior
too.
Do I anything wrong?
Is that really a Bug? => exists a workaround?
Thanks ahead
Jörg Hundertmarck
Ps.: Please excuse the poor english
--
Summary: missing std::wstring support
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hundertmarck at boehme-weihs dot de
CC: gcc-bugs at gcc dot gnu dot org,hundertmarck at boehme-
weihs dot de
GCC build triplet: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19725
[Bug target/19720] missing braces around initializer
--- Additional Comments From ca50015 at yahoo dot com 2005-01-31 16:22 --- yes, i'm using nptl. glibc was configured like this: --prefix=/usr --with-tls --enable-add-ons=nptl --enable-kernel=2.6.10 --with-headers=/src/linux-2.6.10/include i tried create a new '/usr/include' and copy "/src/linux-2.6.10/include/asm" "/src/linux-2.6.10/include/asm-generic" "/src/linux-2.6.10/include/linux" wont work, leave /usr/include as is also wont work. which preprocessed source should i attach? thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug tree-optimization/19726] New: suboptimal constructor generated
1. code below compiles into many instructions like "movl $0, 16(%eax)", should
have been "stosw" since all initializations are zeros. Even if one or two are
skipped in the middle still bulk stosw should be used.
2. Even when class E with external constructor uncommented this shouldn't change
since constructor can't change any data in C.
Yuri
code
class E {
// int j;
public: E();
};
class C {
int h, i, j, k, l;
// E e;
int m, n, o, p, q, r, s, t, u, v;
public:
C();
};
C::C() : h(0), i(0), j(), k(0), l(0), m(0), n(0), o(0), p(0), q(0), r(0), s(0),
t(0), u(0), v(0) { }
--
Summary: suboptimal constructor generated
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-01-31 16:38 --- Subject: Re: gnat tools not buildable cross > I don't think so. When you get into the libada directory, > CC="$(CC_FOR_TARGET)" > and all hope is lost of having the tools work in a cross configuration. That is wrong, ada/Makefile.in is designed to support this configuration, and use the native gnat bootstrap compiler instead of $(CC) to build the tools in the case of cross compilation. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug libstdc++/19725] missing std::wstring support
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39 --- *** This bug has been marked as a duplicate of 17005 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19725
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39 --- *** Bug 19725 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hundertmarck at boehme-weihs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 16:59 --- I found problem: At FreeBSD intl.h placed in /usr/local/include and gcc 3.4.* not search by default /usr/local/include for system headers (I check this for system compiler gcc version 3.4.2 [FreeBSD] 20040728 and gcc 3.4.3) gcc/intl/configure check intl.h by run test with command line: gcc -o conftest -g -O2 conftest.c 1>&5 and fail. As result if gcc 4.0 bootstrap using gcc 3.4.* we have gcc 4.0 with disabled intl support :((( -- What|Removed |Added CC||ljrittle at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
17:02 ---
This looks promising.
I'll do a full check later.
Thomas
--- transfer.c.orig 2005-01-31 18:03:12.0 +0100
+++ transfer.c 2005-01-31 18:04:00.0 +0100
@@ -150,6 +150,14 @@
else
p = base = data;
+ /* If we have seen the end of the record already, we just
+ * return blanks.
+ */
+ if (sf_seen_eor) {
+memset(base,' ',*length);
+return base;
+ }
+
memset(base,'\0',*length);
current_unit->bytes_left = options.default_recl;
@@ -1222,8 +1230,11 @@
case FORMATTED_SEQUENTIAL:
length = 1;
/* sf_read has already terminated input because of an '\n' */
- if (sf_seen_eor)
- break;
+ if (sf_seen_eor)
+ {
+ sf_seen_eor = 0;
+ break;
+ }
do
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31 17:23 --- (In reply to comment #3) > gcc 3.2.x was definitely not stable on opteron. As far as I remember, > opteron support was developed by SuSE on the hammer branch and by > redhat on top of their 3.2.x based compiler. I believe that both folded > their changes back into the 3.3.x series, but 3.2.3 is certainly not > a good idea to use on that system. > > Besides that, we stopped support for 3.2.3. Please test with a newer > release, and if there are still problems, open a new PR. > > Thanks > Wolfgang Thanks for the early replies. I downloaded 3.4.3 from sources.redhat.com. When i am tring to install the problem is still there. And there is no change in the status with 3.3.5 also. Is the patch for 3.2.3 is available? Which version shall i use? -- Thanks & Regards, Sitaram. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
--- Additional Comments From law at redhat dot com 2005-01-31 17:30 --- Subject: Re: [4.0 Regression] A side effect is missed in 0 % a++. On Mon, 2005-01-31 at 14:44 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 > 14:44 --- > Confirmed via Roger on the mailing list. Go ahead and assign it to me. I'll try to nail it down a little later today. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug tree-optimization/19723] [4.0 Regression] A side effect is missed in 0 % a++.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |law at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19723
[Bug middle-end/19650] [4.0 Regression] miscompiling of array acess of (int)(a==2)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31 18:01 --- Subject: Bug 19650 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-31 18:00:52 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr19650.C Log message: 2005-01-31 Roger Sayle <[EMAIL PROTECTED]> Dale Johannesen <[EMAIL PROTECTED]> PR middle-end/19650 * fold-const.c (fold_binary_op_with_conditional_arg): Make types match original operands, before STRIP_NOPS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7341&r2=2.7342 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.499&r2=1.500 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4963&r2=1.4964 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19650.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug target/19720] missing braces around initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:16 --- Not a gcc bug so closing. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
[Bug c++/19726] suboptimal constructor generated
-- What|Removed |Added Component|tree-optimization |c++ Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:20 --- I think it is time to check your memory and/or hardware, this works for so many other people. -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug middle-end/19650] [4.0 Regression] miscompiling of array acess of (int)(a==2)
--- Additional Comments From dalej at apple dot com 2005-01-31 18:27 --- Fixed by patch above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug c/19727] New: i386 regparm attribute mismatch does not generate warning
A "gcc -Wall -c test.c" of the following compiles cleanly while it should generate an error as incorrect code will be produced for function calls to foo() via bar(). int foo(void) __attribute__((regparm(3))); int (*bar)(void) __attribute__((regparm(0))) = foo; -- Summary: i386 regparm attribute mismatch does not generate warning Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bcrl at kvack dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19727
[Bug target/19727] i386 regparm attribute mismatch does not generate warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:43 --- Fixed in 3.4.0: : Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2). : Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Keywords||diagnostic Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19727
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 18:44 --- And PR18360 indeed related to this bug report. If gcc 3.4.3 bootstraped using installed gcc 4.0: gcc/intl/configure test using gcc 4.0 and found /usr/local/include/libintl.h and remember this But stage1 gcc 3.4.3 not search in /usr/local/include and fail compile stage2 with error: In file included from c-parse.y:42: /home/wanderer/pkg/build/gcc/src/gcc_34/gcc/gcc/intl.h:31:21: libintl.h: No such file or directory I think rebuilding gcc/intl before each stage using previous build C compiler can fix PR19656 and PR18360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug target/19726] suboptimal constructor generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 18:49 --- Confirmed, note this is either a front-end bug because the front-end produces multiple stores or a target bug for not combining those stores to one store string instruction. Also if one initializer is missing it turns out it is undefined if you access that data. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c++ |target Ever Confirmed||1 GCC target triplet||i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-01-31 18:49:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-31 18:57 --- Adding pragma visibility push(default)/pop to the basic_string.h header (or to the std_string.h header, for that matter) does *not* fix the issue for me. Is anyone able to confirm this or viceversa? (binutils 2.15.91.0.2 on x86_64) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31 19:01 --- (In reply to comment #5) > I think it is time to check your memory and/or hardware, this works for so many other people. Yeah, can you help me insorting out the issue. I am providing some of the info here. As i noticed from the gcc installation guide a list of prerequesites are provided. I am missing some of the tools in Tools/Packages necessary for modifing gcc. they are 1. requisite is gettext 0.12 but iam having 0.11.4 version 2. requisite is autogen 5.5.4 but iam not having 3. requisite is guile 1.4.1 but iam not having 4. requisite is tex 4.2 but iam not having Does these differences effect the istallation? As u mentions i should check my memory n hardware, in what should i chek Can u please elobarate. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 19:04 --- I think you'll also want to try using -fno-gcse. The gcse pass is hoisting values out of your loop (as it is supposed to), except that we don't have enough registers to hold it all, so the values get spilled back to the stack. This is a known problem. If we had anything approaching a decent register allocator, we'd be able to move these values (known to be loop invariant) back inside the loop instead of spilling them. Of course, we've got multiple passes that hoist values out of loops, and using -fno-gcse only prevents half of the spilled values from being moved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug other/19722] gcc 3.2.3 installation problem on x86
--- Additional Comments From bangerth at dealii dot org 2005-01-31 19:30 --- In general, you have to make sure that you have the required versions of other packages. As for helping you to sort out hardware problems -- please look elsewhere on the web, this forum here is concerned with gcc development, not with helping users with their hardward, sorry. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:56 --- Created an attachment (id=8117) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8117&action=view) diff of debugging dumps between amd64 and ia64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:59 --- I have just built a new gcc targeted for m68hc11 with gcc-3.4, and the problem is still there, both with default optimizations and with -O2. I have also run 'gcc -da' on the testcase on both amd64 and ia64 hosts, and then I have done a diff between the two (see attachement, --- is amd64, +++ is ia64). It seems they started to differ at prl19724_testcase.c.24.greg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 --- Subject: Re: [meta-bug] optimizations that CSE still catches My numbers for not disabling CSE completely but disabling path following are a lot less pessimistic. This was on an AMD Opteron at 1600MHz: GCC was configured as: configure --enable-threads=posix --enable-languages="c,c++,f95" GCC bootstrap times for 'make -j1 bootstrap && make install': Bootstrap time base compiler: 2208 s Bootstrap time peak compiler: 2150 s (-2.6%) SPECint 64 bits Total time for base compilation: 192 s Total time for peak compilation: 180 s (-6.7%) base peakpeak/base 164.gzip 794799+0.63% 175.vpr 729715-1.92% 176.gcc 958963+0.52% 181.mcf 410411+0.24% 186.crafty1362 1380 +1.32% 197.parser558558= 252.eon X X 253.perlbmk 962964+0.21% 254.gap 774776+0.26% 255.vortex1159 1162 +0.26% 256.bzip2 779772-0.90% 300.twolf 836876+4.78% SPECfp 64 bits Total time for base compilation: 212 s Total time for peak compilation: 208 s (-1.9%) base peakpeak/base 168.wupwise 781793+1.53% 171.swim 690687-0.43% 172.mgrid 513514+0.02% 173.applu 624624= 177.mesa 1000998-0.20% 178.galgel X X 179.art 941953+1.28% 183.equake817820+0.37% 187.facerec 674677+0.44% 188.ammp 859859= 189.lucas 858858= 191.fma3d 699698-0.14% 200.sixtrack 382382= 301.apsi 770771+0.12% SPECint 32 bits Total time for base compilation: 257 s Total time for peak compilation: 246 s (-4.5%) base peakpeak/base 164.gzip 696700+0.57% 175.vpr 691710+2.74% 176.gcc 884875-1.02% 181.mcf 528530+0.38% 186.crafty920922+0.22% 197.parser629634+0.79% 252.eon 970963-0.72% 253.perlbmk 935938+0.32% 254.gap X X 255.vortex X X 256.bzip2 678681+0.04% 300.twolf 974966-0.82% SPECfp 32 bits Total time for base compilation: 210 s Total time for peak compilation: 204 s (-2.9%) base peakpeak/base 168.wupwise 672658-2.08% 171.swim 692696+0.58% 172.mgrid 370370= 173.applu 580580= 177.mesa 678655-3.39% 178.galgel X X 179.art 484483-0.21% 183.equake822821-0.12% 187.facerec 616617+0.16% 188.ammp 712713+0.14% 189.lucas 693695+0.20% 191.fma3d 716716= 200.sixtrack 422422= 301.apsi 685685= The SPEC numbers are the mean of three runs, so that's pretty solid. Index: params.def === RCS file: /cvs/gcc/gcc/gcc/params.def,v retrieving revision 1.53 diff -u -3 -p -r1.53 params.def --- params.def 20 Jan 2005 12:45:12 - 1.53 +++ params.def 31 Jan 2005 17:09:21 - @@ -321,7 +321,7 @@ DEFPARAM(PARAM_MIN_CROSSJUMP_INSNS, DEFPARAM(PARAM_MAX_CSE_PATH_LENGTH, "max-cse-path-length", "The maximum length of path considered in cse", -10, 0, 0) +1, 0, 0) /* The cost of expression in loop invariant motion that is considered expensive. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:18 --- -fno-gcse is a godsend, instant speedup and most of the sillyness when inlining is gone. Now i've applied both your patches, and while there's promising they also triggers their own nastyness; gcc is so fond of memory inputs that it dumps stuff on the stack only to address them some instructions latter (well, that's my interpretation :). For example, 4010c3: 0f 28 6c 13 30 movaps 0x30(%ebx,%edx,1),%xmm5 4010c8: 0f 28 f9movaps %xmm1,%xmm7 4010cb: 0f 28 cbmovaps %xmm3,%xmm1 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp) 4010d3: 0f 59 cemulps %xmm6,%xmm1 4010d6: 0f 59 c4mulps %xmm4,%xmm0 4010d9: 0f 28 6c 16 30 movaps 0x30(%esi,%edx,1),%xmm5 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3 or 40119d: 0f c2 c1 01 cmpltps %xmm1,%xmm0 4011a1: 0f 29 04 24 movaps %xmm0,(%esp) 4011a5: 0f 28 c5movaps %xmm5,%xmm0 4011a8: 0f c2 c1 01 cmpltps %xmm1,%xmm0 4011ac: 0f 28 c8movaps %xmm0,%xmm1 4011af: 0f 56 0c 24 orps (%esp),%xmm1 Other than those quirks, it looks better to me. Just to be sure i've tried that patched version on my app, and it's slower than the unpatched version (both with -fno-gcse). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31 20:22 --- Isn't this the same as PR 16925? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 20:28 --- (In reply to comment #5) > Isn't this the same as PR 16925? No, this is different. The patch attached to PR 16925 fixes the problem on all three hosts (amd64, ia64 and alpha). And the problem is on a different file, with a different testcase. BTW, I have checked all the differences between amd64, alpha and ia64, and I have found one: alpha and amd64 are using 40-bit address space whereas ia64 is using a 64-bit address space. There is some signedness error (comparison between signed and unsigned during the build). If the full 64-bit range is used, I think it may cause such kind of error. And addresses return by gcc on ia64 (such as 0x202dc720) are using all the bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:35 --- Hmm, there's something fishy with _mm_set1_epi32. With your patches there's no stack copy anymore but, with http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 testcase, i get: 00401080 : 401080: 66 0f 6e 4c 24 04 movd 0x4(%esp),%xmm1 401086: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40108b: c3 ret 00401090 : 401090: 8b 44 24 04 mov0x4(%esp),%eax 401094: 66 0f 6e 08 movd (%eax),%xmm1 401098: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40109d: c3 ret 00401050 : 401050: 8b 44 24 04 mov0x4(%esp),%eax 401054: 66 0f 6e 08 movd (%eax),%xmm1 401058: 66 0f 70 c1 00 pshufd $0x0,%xmm1,%xmm0 40105d: c3 ret ... and that's quite bogus :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug libgcj/19728] New: libgcj Gnu.java missing SHA-160
Index: Gnu.java
===
RCS file: /cvsroot/gcc/gcc/libjava/gnu/java/security/provider/Gnu.java,v
retrieving revision 1.7
diff -u -r1.7 Gnu.java
--- Gnu.java 15 Nov 2004 20:02:04 - 1.7
+++ Gnu.java 31 Jan 2005 20:47:01 -
@@ -129,6 +129,7 @@
// Format "Alias", "Actual Name"
put("Alg.Alias.MessageDigest.SHA1", "SHA");
put("Alg.Alias.MessageDigest.SHA-1", "SHA");
+put("Alg.Alias.MessageDigest.SHA-160", "SHA");
// Algorithm Parameters
put("AlgorithmParameters.DSA",
--
Summary: libgcj Gnu.java missing SHA-160
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ovidr at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19728
[Bug libgcj/19729] New: libgcj DSASignature.java null pointer exception
appRandom might be null in DSASignature (it is not initialized), yet in the method "public byte[] engineSign()" appRandom is used which causes an NPE. Casey Marshall sent me the attached replacement DSASignature.java file and it works. -- Summary: libgcj DSASignature.java null pointer exception Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ovidr at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19729
[Bug libgcj/19729] libgcj DSASignature.java null pointer exception
--- Additional Comments From ovidr at users dot sourceforge dot net 2005-01-31 21:02 --- Created an attachment (id=8118) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8118&action=view) The file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19729
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:02 --- (In reply to comment #22) No, it isn't. Look at your functions again. The assembly that you pasted is 100% perfect. You cannot improve on that in any way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug other/19730] New: segfault in cp-demangle
gcc version 3.4.2 [FreeBSD] 20040728
# c++filt _Z4test1AILZ2buEE
Segmentation fault (core dumped)
gcc version 3.2
# c++filt _Z4test1AILZ2buEE
test(A)
Quick workaround patch based on 3.2 libiberty sources.
(similar to be done over libiberty demangler)
Index: cp-demangle.c
===
RCS file: /home/ncvs/src/contrib/gcc/cp-demangle.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 cp-demangle.c
--- cp-demangle.c 28 Jul 2004 03:11:34 - 1.1.1.5
+++ cp-demangle.c 31 Jan 2005 21:03:22 -
@@ -2242,6 +2242,47 @@
return al;
}
+static struct demangle_component *
+d_literal (di)
+ struct d_info *di;
+{
+ struct demangle_component *type;
+ enum demangle_component_type t;
+ const char *s;
+
+ type = cplus_demangle_type (di);
+
+ /* If we have a type we know how to print, we aren't going to
+ print the type name itself. */
+ if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
+ && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
+di->expansion -= type->u.s_builtin.type->len;
+
+ /* Rather than try to interpret the literal value, we just
+ collect it as a string. Note that it's possible to have a
+ floating point literal here. The ABI specifies that the
+ format of such literals is machine independent. That's fine,
+ but what's not fine is that versions of g++ up to 3.2 with
+ -fabi-version=1 used upper case letters in the hex constant,
+ and dumped out gcc's internal representation. That makes it
+ hard to tell where the constant ends, and hard to dump the
+ constant in any readable form anyhow. We don't attempt to
+ handle these cases. */
+
+ t = DEMANGLE_COMPONENT_LITERAL;
+ if (d_peek_char (di) == 'n')
+{
+ t = DEMANGLE_COMPONENT_LITERAL_NEG;
+ d_advance (di, 1);
+}
+ s = d_str (di);
+ while (d_peek_char (di) != 'E')
+d_advance (di, 1);
+
+ return d_make_comp (di, t, type, d_make_name (di, s, d_str (di) - s));
+}
+
+
/* ::=
::= X E
::=
@@ -2263,7 +2304,19 @@
return ret;
case 'L':
- return d_expr_primary (di);
+ d_advance (di, 1);
+
+ if(d_peek_char(di) == 'Z') {
+d_advance (di, 1);
+
+ ret = d_encoding(di, 0);
+ } else
+ ret = d_literal(di);
+
+ if (d_next_char (di) != 'E')
+ return NULL;
+
+ return ret;
default:
return cplus_demangle_type (di);
@@ -2392,41 +2445,8 @@
if (d_peek_char (di) == '_')
ret = cplus_demangle_mangled_name (di, 0);
else
-{
- struct demangle_component *type;
- enum demangle_component_type t;
- const char *s;
-
- type = cplus_demangle_type (di);
-
- /* If we have a type we know how to print, we aren't going to
-print the type name itself. */
- if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
- && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
- di->expansion -= type->u.s_builtin.type->len;
-
- /* Rather than try to interpret the literal value, we just
-collect it as a string. Note that it's possible to have a
-floating point literal here. The ABI specifies that the
-format of such literals is machine independent. That's fine,
-but what's not fine is that versions of g++ up to 3.2 with
--fabi-version=1 used upper case letters in the hex constant,
-and dumped out gcc's internal representation. That makes it
-hard to tell where the constant ends, and hard to dump the
-constant in any readable form anyhow. We don't attempt to
-handle these cases. */
-
- t = DEMANGLE_COMPONENT_LITERAL;
- if (d_peek_char (di) == 'n')
- {
- t = DEMANGLE_COMPONENT_LITERAL_NEG;
- d_advance (di, 1);
- }
- s = d_str (di);
- while (d_peek_char (di) != 'E')
- d_advance (di, 1);
- ret = d_make_comp (di, t, type, d_make_name (di, s, d_str (di) - s));
-}
+ret = d_literal(di);
+
if (d_next_char (di) != 'E')
return NULL;
return ret;
--
Summary: segfault in cp-demangle
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: unicorn at freeshell dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-freebsd5.3
GCC host triplet: i386-unknown-freebsd5.3
GCC target triplet: i386-unknown-freebsd5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19730
[Bug rtl-optimization/19680] sub-optimial register allocation with sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:12 --- (In reply to comment #21) > 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp) > 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3 > 4011a1: 0f 29 04 24 movaps %xmm0,(%esp) > 4011af: 0f 56 0c 24 orps (%esp),%xmm1 These instruction patterns didn't change. I only fibbed wrt "int" inputs. It's not impossible that some of this is due to adding the const to the builtin signatures, but... > Just to be sure i've tried that patched version on my app, and it's slower > than the unpatched version (both with -fno-gcse). So, overall the combination of the two patches is a lose? How about each patch individually? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug other/19730] segfault in cp-demangle
--- Additional Comments From pcarlini at suse dot de 2005-01-31 21:20 --- Ian, can you have a look? Mainline __cxa_demangle returns -2. -- What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19730
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From law at redhat dot com 2005-01-31 21:35 --- Subject: Re: [meta-bug] optimizations that CSE still catches On Mon, 2005-01-31 at 20:14 +, stevenb at suse dot de wrote: > --- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 > --- > Subject: Re: [meta-bug] optimizations that CSE still catches > > My numbers for not disabling CSE completely but disabling path following > are a lot less pessimistic. This was on an AMD Opteron at 1600MHz: Right. That's what I'd focus on first -- that's what I was looking at when I realized eons ago when I realized that if we don't do a good job at jump threading, then we have little hope of ever drastically simplifying CSE. I've been stuck in jump threading hell ever since :-) Note I would _STRONGLY_ recommend people look at more than just the compiler when evaluating the old CSE code. In particular it is important that we look at things like 64bit arithmetic on 32bit hosts (which happens often in kernels, but not nearly as often in user level benchmarks). jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
