[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #13 from mkl at pengutronix dot de 2006-11-29 09:55 --- Created an attachment (id=12705) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12705&action=view) fix target linker emulation for arm elf and eabi (take 3) If you try to build a big-endian eabi toolchain, you need another fix (see patch of gcc/config/arm/linux-eabi.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-29 10:38 ---
If one uses -mfpmath=387 or -mfpmath=sse,387, the speed also dramatically
increases.
Results with test case below on a Athlon64:
icc -O3 test.c; time ./a.out
d=12.216410, r=10.26
real0m2.549s; user0m2.548s; sys 0m0.000s
gcc -ftree-vectorize -O3 -msse3 -ffast-math -lm test.c
d=12.216410, r=10.26
real0m5.444s; user0m5.444s; sys 0m0.000s
gcc -ftree-vectorize -O3 -msse3 -mfpmath=sse,387 -ffast-math -lm test.c
d=12.216410, r=10.26
real0m1.363s; user0m1.192s; sys 0m0.000s
#include
#include
int main() {
double r,d;
d = 0.0;
for(r=0.0; r < 10.0; r += 0.001)
d = fmod(d,5.0)+r;
printf("d=%f, r=%f\n",d,r);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-29 10:49 --- So another possibility is to adjust the 387 patterns to be enabled even without TARGET_MIX_SSE_I387. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug libfortran/30015] New: Intrinsic date_and_time can go back in time
In date_and_time.c, 'time' is called. If the routine then goes on to call 'gettimeofday', it extracts the milliseconds value from the 'gettimeofday' call, but gets the seconds value from the old call to 'time'. This can result in consecutive times of (say) 2006 11 29 124 34 999 2006 11 29 124 340 being generated. Notice that the seconds in the later call have not 'ticked over', because they refer to the earlier time value accessed by 'time', while the milliseconds refer to the "correct" value accessed by gettimeofday. Here is our test code: Test program for DATE_AND_TIME PROGRAM DATE_AND_TIME_TEST ! .. Implicit None Statement .. IMPLICIT NONE ! .. Parameters .. INTEGER, PARAMETER :: NOUT = 6 INTEGER, PARAMETER :: WP = KIND(0.0D0) ! .. Non-Generic Interface Blocks .. INTERFACE FUNCTION ORDER_TIME(ITIME1,ITIME2) ! .. Function Return Value .. INTEGER :: ORDER_TIME ! .. Array Arguments .. INTEGER, INTENT (IN) :: ITIME1(7), ITIME2(7) END FUNCTION ORDER_TIME END INTERFACE ! .. Local Scalars .. REAL (KIND=WP) :: E, ETOL, EXPE, T INTEGER :: I, N, NFAILS LOGICAL :: PASS ! .. Local Arrays .. INTEGER :: DATE_TIME(8), ITIME1(7), ITIME2(7) ! .. Intrinsic Functions .. INTRINSIC ABS, DATE_AND_TIME, KIND, MIN ! .. Executable Statements .. CONTINUE PASS = .TRUE. EXPE = 2.718281828E0_WP ! Make up to 1 calls of DATE_AND_TIME and check that they return ! monotonic non-decreasing times, by calling ORDER_TIME. NFAILS = 0 CALL DATE_AND_TIME(VALUES=DATE_TIME) ITIME2(1:3) = DATE_TIME(1:3) ITIME2(4:7) = DATE_TIME(5:8) ! Output start time. WRITE (NOUT,FMT=1) ITIME2(1:7) I = 2 DO ! Save the old time in ITIME1. ITIME1(1:7) = ITIME2(1:7) ! Delay a bit by computing e. ETOL = 0.001_WP E = 1.0E0_WP T = 1.0E0_WP DO N = 1, 10 - MIN(I,6) T = T/N E = E + T END DO ! This test is just so that E gets used and the loop ! above isn't optimised away. IF (ABS(E-EXPE)>ETOL) THEN IF (PASS) THEN PASS = .FALSE. WRITE (NOUT,FMT=9) E, EXPE END IF END IF ! Get the new time in ITIME2. CALL DATE_AND_TIME(VALUES=DATE_TIME) ITIME2(1:3) = DATE_TIME(1:3) ITIME2(4:7) = DATE_TIME(5:8) IF (ORDER_TIME(ITIME1,ITIME2)==1 .AND. NFAILS<5) THEN NFAILS = NFAILS + 1 PASS = .FALSE. WRITE (NOUT,FMT=8) ITIME1, ITIME2 END IF ! Continue round the loop up to at most 1 times, unless at ! least two different times have been found and we've done ! the loop at least 1000 times. IF ((ORDER_TIME(ITIME1,ITIME2)/=-1 .AND. I<1) .OR. I<1000) THEN I = I + 1 ELSE EXIT END IF END DO ! Make one final check to ensure that all the times in the loop ! above were not identical. ! Output end time. WRITE (NOUT,FMT=0) ITIME2(1:7) IF (ORDER_TIME(ITIME1,ITIME2)/=-1 .AND. NFAILS<5) THEN PASS = .FALSE. WRITE (NOUT,FMT=7) ITIME1, ITIME2 END IF IF (PASS) THEN WRITE (NOUT,FMT=6) ELSE WRITE (NOUT,FMT=5) END IF 9 FORMAT (1X/1X,'Computed e as ',1P,E13.5,' instead of ',E13.5) 8 FORMAT (1X/1X,'Two consecutive calls of DATE_AND_TIME returned:', & 2(/1X,7I5)/2X, & '- the first should be not later than the second but is.') 7 FORMAT (1X/1X,'Two calls of DATE_AND_TIME returned:',2(/1X,7I5)/2X, & '- the first should be earlier than the second but is not.') 6 FORMAT (1X/1X,'TEST OF DATE_AND_TIME PASSED OK') 5 FORMAT (1X/1X,'TEST OF DATE_AND_TIME FAILS') 1 FORMAT (1X,'*** Started at',7I5) 0 FORMAT (1X/1X,'* Ended at',7I5) END PROGRAM DATE_AND_TIME_TEST FUNCTION ORDER_TIME(ITIME1,ITIME2) ! .. Implicit None Statement .. IMPLICIT NONE ! .. Function Return Value .. INTEGER :: ORDER_TIME ! .. Parameters .. INTEGER, PARAMETER :: WP = KIND(0.0D0) ! .. Array Arguments .. INTEGER, INTENT (IN) :: ITIME1(7), ITIME2(7) ! .. Local Scalars .. INTEGER :: I ! .. Intrinsic Functions .. INTRINSIC KIND ! .. Executable Statements .. CONTINUE ! Compare the integer array format times. I = 1 DO IF (ITIME1(I)==ITIME2(I) .AND. I<7) THEN I = I + 1 ELSE EXIT END IF END DO IF (ITIME1(I)http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30015
[Bug libfortran/30015] Intrinsic date_and_time can go back in time
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-29 14:12 --- Confirm. (Though I couldn't reproduce the problem with gcc 4.2 and gcc 4.1 and the example program.) The proposed solution is to change local_time = *localtime (<); UTC_time = *gmtime (<); [...] values[6] = local_time.tm_sec; [...] gettimeofday (...) values[7] = tp.tv_usec / 1000; to gettimeofday (...) values[7] = tp.tv_usec / 1000; [...] local_time = *localtime (<); UTC_time = *gmtime (<); [...] values[6] = local_time.tm_sec; -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-29 14:12:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30015
[Bug c++/29022] [4.0/4.1/4.2/4.3 regression] ICE using operator int in invalid class hierarchy
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-11-29 15:19 --- Subject: Bug 29022 Author: lmillward Date: Wed Nov 29 15:19:39 2006 New Revision: 119318 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119318 Log: PR c++/29022 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for any base classes. Only process them if the opening brace was found. * g++.dg/inherit/virtual2.C: New test. * g++.dg/inherit/virtual3.C: Likewise. * g++.old-deja/g++.bugs/900121_05.C: Adjust error markers. * g++.dg/inherit/error2.C: Likewise. * g++.dg/template/instantiate1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/inherit/virtual2.C trunk/gcc/testsuite/g++.dg/inherit/virtual3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/inherit/error2.C trunk/gcc/testsuite/g++.dg/template/instantiate1.C trunk/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-11-29 15:20 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE using operator int in |using operator int in |invalid class hierarchy |invalid class hierarchy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/30016] New: internal compiler error: in convert_move, at expr.c:362
I find no description for "triplet", so guessing at its use, and see no method
of attaching .ii so attempting to fit all info in this form.
Problem seems to be from reinterpret_cast between vectors and unions of vectors
with arrays of scalars.
Occurred in machine-generated code, have not been able to substantially
simplify.
Error persists with -march=pentium4 -msse2 switches so is independent of
whether
vectors are generated or just simulated as array.
Identical error message occurs in gcc built from 4.1.1 sources on a PowerPC G4.
Error does not occur if I change to C-style casts and change extension to .c.
Unfortunately, semantics of C++ casting seem to change the C-style cast in
error.cpp to a static_cast, which then encounters a semantic error:
error2.cpp:144: error: no matching function for call to __v4F::__v4F(float
__vector__&)
error2.cpp:17: note: candidates are: __v4F::__v4F()
error2.cpp:17: note: __v4F::__v4F(const __v4F&)
Thus the attempt to generate a reinterpret_cast leading to discovery of bug.
gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
gcc -O3 -o error.o error.cpp
error.cpp: In function void work_Fused_Pre_iDC_Pos_iDC_158__2(int):
error.cpp:245: internal compiler error: in convert_move, at expr.c:362
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccqrXNUl.out file, please attach this to
your bugreport.
// /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -quiet -D_GNU_SOURCE
error.cpp -quiet -dumpbase error.cpp -mtune=generic -auxbase error -O3 -o -
-frandom-seed=0
# 1 "error.cpp"
# 1 ""
# 1 ""
# 1 "error.cpp"
volatile int __print_sink__;
# 16 "error.cpp"
typedef float __v_4F __attribute__ ((vector_size (16)));
typedef union {__v_4F v; float a[4];} __v4F;
int __max_iteration;
int BUFFER_0_1[1023 + 1];
int HEAD_0_1 = 0;
int TAIL_0_1 = 0;
float BUFFER_1_2[1023 + 1];
int HEAD_1_2 = 0;
int TAIL_1_2 = 0;
float BUFFER_2_3[1023 + 1];
int HEAD_2_3 = 0;
int TAIL_2_3 = 0;
void init_AnonFilter_a0__261_44__1();
void work_AnonFilter_a0__261_44__1(int);
void init_Fused_Pre_iDC_Pos_iDC_158__2();
void work_Fused_Pre_iDC_Pos_iDC_158__2(int);
void FileWriter__301_78__work__4(int);
int main(int argc, char **argv) {
int a;
int n;
# 48 "error.cpp"
init_Fused_Pre_iDC_Pos_iDC_158__2();
for (n = 0; n < (__max_iteration ); n++) {
HEAD_1_2 = 0;
TAIL_1_2 = 0;
work_AnonFilter_a0__261_44__1(1024 );
HEAD_2_3 = 0;
TAIL_2_3 = 0;
work_Fused_Pre_iDC_Pos_iDC_158__2(1 );
FileWriter__301_78__work__4(1024 );
}
return 0;
}
inline void __push__0(int data) {
BUFFER_0_1[HEAD_0_1]=data;
HEAD_0_1++;
}
inline void __push__1(float data) {
BUFFER_1_2[HEAD_1_2]=data;
HEAD_1_2++;
}
float v = 0.0f;
void work_AnonFilter_a0__261_44__1(int n){
for (
; (0 < n); (n--)) {{
__push__1(v++);
}
}
}
__v_4F coeff__268__309__2[16][16];
__v_4F coeff__285__329__2[16][16];
inline float __pop__2n(int n) {
float res=BUFFER_1_2[TAIL_1_2];
TAIL_1_2+=n;
return res;
}
inline float __peek__2(int offs) {
return BUFFER_1_2[TAIL_1_2+offs];
}
inline void __push__2(float data) {
BUFFER_2_3[HEAD_2_3]=data;
HEAD_2_3++;
}
void init_Fused_Pre_iDC_Pos_iDC_158__2(){
float Cu__275__318 = 0.0f;
int u__276__319 = 0;
int x__277__320 = 0;
float __tmp92 = 0.0f;
(x__277__320 = 0) ;
while ((x__277__320 < 16)) {
(u__276__319 = 0) ;
while ((u__276__319 < 16)) {
(Cu__275__318 = ((float)1.0)) ;
if ((u__276__319 == 0)) {(Cu__275__318 = ((float)0.70710677)) ;
} else {}
(__tmp92 = float)0.5) * Cu__275__318) * ((float)(
(((double)((float)(u__276__319)) * ((float)3.1415927)) * float)2.0) *
((float)(x__277__320))) + ((float)1.0))) / ((float)32.0) ;
(((reinterpret_cast<__v4F>(((coeff__268__309__2)[(int)x__277__320])[(int)u__276__319]).a)[(int)0])
= __tmp92);
(((reinterpret_cast<__v4F>(((coeff__268__309__2)[(int)x__277__320])[(int)u__276__319]).a)[(int)1])
= __tmp92);
(((reinterpret_cast<__v4F>(((coeff__268__309__2)[(int)x__277__320])[(int)u__276__319]).a)[(int)2])
= __tmp92);
(((reinterpret_cast<__v4F>(((coeff__268__309__2)[(int)x__277__320])[(int)u__276__319]).a)[(int)3])
= __tmp92);
(u__276__319++);
}
(x__277__320++);
}
float Cu__292__338 = 0.0f;
int u__293__339 = 0;
int x__294__340 = 0;
float __tmp93 = 0.0f;
(x__2
[Bug bootstrap/30008] bootstrapping failure: multiple function definitions
--- Comment #2 from eesrjhc at bath dot ac dot uk 2006-11-29 15:48 --- I think this is the same as PR 29867 -- eesrjhc at bath dot ac dot uk changed: What|Removed |Added CC||eesrjhc at bath dot ac dot ||uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30008
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #4 from ubizjak at gmail dot com 2006-11-29 15:58 --- (In reply to comment #3) > So another possibility is to adjust the 387 patterns to be enabled even > without > TARGET_MIX_SSE_I387. > Considering the fact that even solaris x86_64 libm [1] uses these functions for DFmode and SFmode, I propose that we use only "TARGET_USE_FANCY_MATH_387" constraint. [1] http://svn.genunix.org/repos/devpro/trunk/usr/src/libm/src/i386/amd64/ -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug tree-optimization/23744] VRP does not merge discontinuous ranges of PHIs
--- Comment #7 from baldrick at gcc dot gnu dot org 2006-11-29 16:00 --- Subject: Bug 23744 Author: baldrick Date: Wed Nov 29 16:00:07 2006 New Revision: 119320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119320 Log: PR tree-optimization/23744 * tree-vrp.c (vrp_meet): do not require ranges to intersect. * testsuite/gcc.dg/tree-ssa/pr23744.c: new test. * testsuite/gcc.dg/tree-ssa/update-threading.c: xfail. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23744.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-29 16:02 --- Can we make sure to always emit proper truncation to SF/DFmode if not TARGET_MIX_SSE_I387? Just in case two fprem instructions follow each other and so we don't truncate by moving to memory or SSE registers. It would be bad to let excess precision (aka bug 323) sneak in for fpmath=sse when we tell people to use that to prevent excess precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug c++/30017] New: ICE in cp_expr_size, at cp/cp-objcp-common.c:101
Between r119279 and r119305 DVL failed to build with ./cc1plus -quiet -o /dev/null /space/rguenther/src/c++bench/html/sandbox/DLV/dl.ii -O dl.C: In function 'void printQueryI(std::ostream&, const INTERPRET&, const GINTERPRET*)': dl.C:800: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE in cp_expr_size, at cp/cp-objcp-common.c:101 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-29 16:33 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-11-29 16:51 --- Subject: Bug 29022 Author: lmillward Date: Wed Nov 29 16:51:32 2006 New Revision: 119322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119322 Log: PR c++/29022 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for any base classes. Only process them if the opening brace was found. * g++.dg/inherit/virtual2.C: New test. * g++.dg/inherit/virtual3.C: Likewise. * g++.old-deja/g++.bugs/900121_05.C: Adjust error markers. * g++.dg/inherit/error2.C: Likewise. * g++.dg/template/instantiate1.C: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/virtual2.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/virtual3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/instantiate1.C branches/gcc-4_2-branch/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29022] [4.0/4.1 regression] ICE using operator int in invalid class hierarchy
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-11-29 16:52 --- Fixed in 4.2. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |using operator int in |using operator int in |invalid class hierarchy |invalid class hierarchy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug tree-optimization/29791] [4.3 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #9 from janis at gcc dot gnu dot org 2006-11-29 17:37 --- This was fixed by http://gcc.gnu.org/viewcvs?view=rev&rev=118754 r118754 | rakdver | 2006-11-13 12:37:29 + (Mon, 13 Nov 2006) which reverted the patch that caused the testcase to start failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-29 17:55 --- Created an attachment (id=12706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12706&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug bootstrap/30018] New: gcc trunk fails to bootstrap on x86_64-unknown-linux-gnu
Building the trunk into an empty directoy with "$GCCDIR/configure" --enable-languages=c,fortran --prefix=/projects/tob/gcc-trunk && make && make install on an openSUSE 10.2rc2 system fails with 'cc1: error: unrecognized command line option "-Wno-overlength-strings'. This is with "make" since I had the feeling "make -j2". Yesterdays build with r119277 was still ok, the error occurs with r119303 up to r119311. Building GCC 4.2 on the same machine works. gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macr os -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/tob/p rojects/gcc/gcc -I/home/tob/projects/gcc/gcc/. -I/home/tob/projects/gcc/gcc/../include -I/home/tob/projects/gcc/gcc/../libcpp/include - I/home/tob/projects/gcc/gcc/../libdecnumber -I../libdecnumber /home/tob/projects/gcc/gcc/tree-ssanames.c -o tree-ssanames.o cc1: error: unrecognized command line option "-Wno-overlength-strings" There are three cc1: ./gcc/cc1 ./stage1-gcc/cc1 ./prev-gcc/cc1 And doing ./gcc/cc1 -quiet -Wno-overlength-strings < /dev/null gives no error. (and no other cc1 is in the path.) If I do now manually make, some files are compiled again, the compilation succeeds but with make install I get immediately the "-Wno-overlength-strings" error again. which gcc returns: /usr/bin/gcc which is 4.1.2 20061115 (prerelease) (SUSE Linux), which also happily accepts "-Wno-overlength-strings". I cannot reproduce it anymore at the moment, but I also had at some point inbetween: xgcc: error trying to exec 'cc1': execvp: No permission. (No of pty is also ok: 7 vs. 4096) -- Summary: gcc trunk fails to bootstrap on x86_64-unknown-linux-gnu Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30018
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #6 from ubizjak at gmail dot com 2006-11-29 18:18 ---
(In reply to comment #5)
> Can we make sure to always emit proper truncation to SF/DFmode if not
> TARGET_MIX_SSE_I387? Just in case two fprem instructions follow each other
> and so we don't truncate by moving to memory or SSE registers. It would be
> bad to let excess precision (aka bug 323) sneak in for fpmath=sse when we
> tell people to use that to prevent excess precision.
We can't make any guarantees about truncation, but ...
... following patch can.
2006-11-29 Uros Bizjak <[EMAIL PROTECTED]>
PR target/XXX
config/i386/i386.md (*truncxfsf2_mixed, *truncxfdf2_mixed): Enable
patterns for TARGET_80387.
(*truncxfsf2_i387, *truncxfdf2_i387): Remove.
(fmod3, remainder3): Enable patterns for SSE math.
Generate truncxf2 instructions for strict SSE math.
for the testcase:
double test1(double a)
{
double x = fmod(a, 1.1);
return fmod(x, 2.1);
}
patched gcc generates (-fno-math-errno for clarity):
test1:
.LFB2:
movsd %xmm0, -16(%rsp)
fldl-16(%rsp)
fldl.LC0(%rip)
fxch%st(1)
.L2:
fprem
fnstsw %ax
testb $4, %ah
jne .L2
fstp%st(1)
fstpl -8(%rsp)
fldl-8(%rsp)
fldl.LC1(%rip)
fxch%st(1)
.L3:
fprem
fnstsw %ax
testb $4, %ah
jne .L3
fstp%st(1)
fstpl -8(%rsp)
movsd -8(%rsp), %xmm0
ret
.LFE2:
In order to get optimal code, truncxf?f2_mixed patterns have to be enabled,
otherwise reload does its job by moving values again to memory and back. The
patch bootstrapps OK, but it will take over night for a regression test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #7 from ubizjak at gmail dot com 2006-11-29 18:20 --- Created an attachment (id=12707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12707&action=view) Patch to enable x87 fprem and fprem1 for SSE math I know that I've forgotten something ;) -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug libfortran/30015] Intrinsic date_and_time can go back in time
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-29 18:25 --- Accept. Thanks for the bugreport and the patch. I actually wanted to write: The proposed solution is to change lt = time() local_time = *localtime (<); UTC_time = *gmtime (<); [...] values[6] = local_time.tm_sec; [...] gettimeofday (...) values[7] = tp.tv_usec / 1000; to lt = time [...] gettimeofday (...) lt = tp.tv_sec; values[7] = tp.tv_usec / 1000; [...] local_time = *localtime (<); UTC_time = *gmtime (<); [...] values[6] = local_time.tm_sec; -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Severity|critical|major Status|NEW |ASSIGNED Last reconfirmed|2006-11-29 14:12:28 |2006-11-29 18:25:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30015
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-11-29 18:36 ---
The patch doesn't like me ;)
[EMAIL PROTECTED]:~/src/trunk/gcc/config/i386$ patch -p0 < /tmp/p
patching file i386.md
Hunk #1 succeeded at 3892 (offset -49 lines).
Hunk #2 succeeded at 3919 (offset -47 lines).
Hunk #3 succeeded at 3990 (offset -47 lines).
Hunk #4 succeeded at 4017 (offset -45 lines).
Hunk #5 FAILED at 15622.
patch: unexpected end of file in patch
what does it generate for
double foo(double a, double b)
{
double x = fmod(a, 1.1);
return x + b;
}
does it do the truncation as part of the x87 -> SSE register move or
is there extra operations involved? If we can get all variants optimal
(store to memory comes to my mind as well) it would be nice!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug c++/29939] Add rvalue references (C++0x)
--- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 --- Recent work: http://mndfck.org/~pedro.lamarao/projects/c++0x/ http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_test/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug libfortran/30011] libgfortran fails on mips-sgi-irix6.5 (IRIX64)
--- Comment #2 from martinol at nrlssc dot navy dot mil 2006-11-29 18:41 --- Argh! Evidently on this system make and gmake are different!! Apologies. Closed. $ /usr/local/bin/make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for mips-sgi-irix6.5 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . $ /usr/local/bin/gmake --version GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. Built for mips-sgi-irix6.5 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . -- martinol at nrlssc dot navy dot mil changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30011
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-29 18:46 --- doesn't fail with 32bits. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-29 18:52 --- Created an attachment (id=12708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12708&action=view) ChangeLog entries for softfp-diff-20061110 These are the ChangeLog entries for the SH specific code. The ChangeLog entries for the target-independent code are included in the patches for the blocking PRs (28618, 29846 and 29847) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug c++/29939] Add rvalue references (C++0x)
--- Comment #4 from fang at csl dot cornell dot edu 2006-11-29 19:00 --- Subject: Re: Add rvalue references (C++0x) On 29 Nov 2006, hhinnant at apple dot com wrote: > --- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 --- > Recent work: > > http://mndfck.org/~pedro.lamarao/projects/c++0x/ > http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_test/ Excellent, these tests look like simple examples to learn from, as a supplement to the technical reports. Thanks for putting this together. I'll be following developments and testing from time to time. I'm highly anticipating this in the upcoming standard. Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug c++/29022] [4.0/4.1 regression] ICE using operator int in invalid class hierarchy
--- Comment #8 from lmillward at gcc dot gnu dot org 2006-11-29 19:02 --- Subject: Bug 29022 Author: lmillward Date: Wed Nov 29 19:01:50 2006 New Revision: 119332 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119332 Log: PR c++/29022 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for any base classes. Only process them if the opening brace was found. * g++.dg/inherit/virtual1.C: New test. * g++.dg/inherit/virtual2.C: Likewise. * g++.old-deja/g++.bugs/900121_05.C: Adjust error markers. * g++.dg/inherit/error2.C: Likewise. * g++.dg/template/instantiate1.C: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/virtual1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/virtual2.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/instantiate1.C branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29022] [4.0 regression] ICE using operator int in invalid class hierarchy
--- Comment #9 from lmillward at gcc dot gnu dot org 2006-11-29 19:02 --- Fixed in 4.1.2. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lmillward at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE using |using operator int in |operator int in invalid |invalid class hierarchy |class hierarchy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-11-29 19:03 --- Created an attachment (id=12709) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12709&action=view) ChangeLog entries for softfp-diff-20061110 The previous version was missing the enumeration of two new files. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Attachment #12708|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug c++/30019] New: g++ did not issue a warning when it (IMO) could have
Hi, I mixed up the following code to reset a ostringstream ostringstream oss; oss << "Stuff"; oss.str() = ""; // Should have been oss.str( "" ); The third line is creating a temporary variable and assigning it the new "" value, then it disappears. Couldn't g++ have warned me of an unused temp? I know I have seen it do things like that before. Thanks -- Summary: g++ did not issue a warning when it (IMO) could have Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dflogeras2 at gmail dot com GCC host triplet: Gentoo Linux GCC target triplet: Target: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30019
[Bug c/30020] New: missing limited range warning for a switch statement
I would expect gcc to issue the same or similar warning for both functions
below but the unreachable label in the switch statement isn't flagged even
with -Wall.
In addition, a new portability warning mode/option would be useful that would
point out cases like those below irrespective of -funsigned-char or other such
options.
$ cat t.c && gcc -Wall -c -funsigned-char t.c
int foo (char c)
{
switch (c) { case -1: return -1; };
return 0;
}
int bar (char c)
{
if (c == -1) return -1;
return 0;
}
t.c: In function `bar':
t.c:9: warning: comparison is always false due to limited range of data type
--
Summary: missing limited range warning for a switch statement
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30020
[Bug other/29717] Make pdf fails, make info/html works; invoke.texi:1079: @include @value{srcdir}
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-29 19:43 --- Works now for me. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29717
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-29 19:47 --- Also fails with 32bit. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-*-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-29 19:47 ---
Further reduced testcase:
class NAMES_ITEM { };
struct ATOM {
const NAMES_ITEM& getPredItem() const { }
};
class ATOMSET {
public:
class FIND_RESULT {
const NAMES_ITEM &pattern;
public:
FIND_RESULT() : pattern(pattern) { }
FIND_RESULT(const FIND_RESULT &f) : pattern(f.pattern) { }
FIND_RESULT(const NAMES_ITEM &pattern2) : pattern(pattern2) { }
void operator=(const FIND_RESULT &f)
{
__builtin_memcpy(this,&f,sizeof(FIND_RESULT));
}
};
void find(const ATOM &pattern, FIND_RESULT &f) {
FIND_RESULT result(pattern.getPredItem());
f = result;
}
};
class INTERPRET {
ATOMSET positive;
public:
void findInPositivePart(const ATOM &pattern, ATOMSET::FIND_RESULT &f)
{
positive.find(pattern,f);
}
};
struct GINTERPRET {
void isTrue (void);
};
extern INTERPRET J;
static GINTERPRET *I;
void printQueryI() {
ATOM pattern;
ATOMSET::FIND_RESULT f;
J.findInPositivePart(pattern,f);
I->isTrue();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug c++/30017] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-29 19:50 --- __builtin_memcpy(this,&f,sizeof(FIND_RESULT)); is most likely the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug libfortran/30015] Intrinsic date_and_time can go back in time
--- Comment #3 from patchapp at dberlin dot org 2006-11-29 19:55 --- Subject: Bug number PR30015 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01987.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30015
[Bug fortran/27996] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
--- Comment #2 from patchapp at dberlin dot org 2006-11-29 20:00 --- Subject: Bug number PR27996 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01989.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #28 from bergner at vnet dot ibm dot com 2006-11-29 20:11 --- Another problem with the current patch, is we get one testsuite regression (gfortran.fortran-torture/compile/defined_type_2.f90 at -O1). For this simple testcase, we end up generating bad assembler: mr 9,sfp instead of: mr 9,1 For some reason, the stack frame pseudo isn't reloaded correctly and we spit out the "sfp" text instead of the correct register number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/29965] OpenMP vs always throw in a loop
--- Comment #3 from jakub at gcc dot gnu dot org 2006-11-29 20:21 --- This is similar to PR27328 which was only fixed for omp parallel (and even then only when not inlined or inlined at most once). Started fixing these omp region with NULL region->exit and/or region->cond issues today, but still have some to finish tomorrow. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-29 20:21:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug c++/29735] [4.0 regression] ICE on "main" returning vector
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-11-29 20:44 --- Fixed in GCC 4.1.2 and later. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.0 regression] ICE on |ICE on "main" returning |"main" returning vector |vector | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29735
[Bug fortran/17711] Wrong operator name in error message
--- Comment #6 from tobi at gcc dot gnu dot org 2006-11-29 20:45 --- I retracted the patch because it causes regressions with user-defined operators. I'm not convinced that this problem is worth doing anything non-trivial as is required, so I'm un-assigning myself. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #9 from ubizjak at gmail dot com 2006-11-29 21:05 ---
(In reply to comment #8)
> The patch doesn't like me ;)
>
> [EMAIL PROTECTED]:~/src/trunk/gcc/config/i386$ patch -p0 < /tmp/p
> patching file i386.md
> Hunk #1 succeeded at 3892 (offset -49 lines).
> Hunk #2 succeeded at 3919 (offset -47 lines).
> Hunk #3 succeeded at 3990 (offset -47 lines).
> Hunk #4 succeeded at 4017 (offset -45 lines).
> Hunk #5 FAILED at 15622.
> patch: unexpected end of file in patch
That is because I have 4 open projects in one branch. In about an hour, the
regression test will finish and I'll post clean patch to gcc-patches.
>
> what does it generate for
>
> double foo(double a, double b)
> {
> double x = fmod(a, 1.1);
> return x + b;
> }
>
> does it do the truncation as part of the x87 -> SSE register move or
> is there extra operations involved? If we can get all variants optimal
> (store to memory comes to my mind as well) it would be nice!
>
movsd %xmm0, -16(%rsp)
fldl-16(%rsp)
fldl.LC0(%rip)
fxch%st(1)
.L2:
fprem
fnstsw %ax
testb $4, %ah
jne .L2
fstp%st(1)
fstpl -8(%rsp)
movsd -8(%rsp), %xmm0
addsd %xmm1, %xmm0
ret
The x87 store represents the truncation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug fortran/30003] Expressions with side effects in array references
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-29 21:21:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug c++/30021] New: [4.3 regression] ICE on invalid parameter for main
The following code snippet crashes the C++ frontend on mainline: == int main(void,char**); == bug.cc:1: error: '' has incomplete type bug.cc:1: error: invalid use of 'void' bug.cc:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in check_main_parameter_types, at c-common.c:1044 Please submit a full bug report, [etc.] Will post a patch soon. -- Summary: [4.3 regression] ICE on invalid parameter for main Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: reichelt at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30021
[Bug c++/30021] [4.3 regression] ICE on invalid parameter for main
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30021
[Bug c++/30022] New: [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
The following code snippet crashes the C++ frontend since GCC 4.0.0:
void foo()
{
int __attribute__((vector_size(8))) v;
v = 1/v;
}
bug.cc: In function 'void foo()':
bug.cc:4: internal compiler error: in type_after_usual_arithmetic_conversions,
at cp/typeck.c:266
Please submit a full bug report, [etc.]
Will post a patch soon.
--
Summary: [4.0/4.1/4.2/4.3 regression] ICE on vector operand in
division
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: reichelt at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #28 from tkoenig at gcc dot gnu dot org 2006-11-29 22:12 --- (In reply to comment #27) Hi Jerry, > The program fails on x86-64-freebsd and never completes the first write. It > just keeps going, and going, and going This is a target specific issue. > My guess is that it has to do with alignment or types. Maybe mixed type > arithmetic, size_t vs gfc_offset. Is size_t 32 bits on freebsd and gfc_offset > 64? I will attempt to change all new variables to gfc_offset and see if that > fixes it. Signedness could indeed be the problem. If that doesn't solve the problem, could you print out the values of - nbytes - to_write_record - to_write_subrecord - dtp->u.p.current_unit->bytes_left - dtp->u.p.current_unit->bytes_left_subrecord at the start of the while loop in write_buf() (but please cast them to long as appropriate :-) This should help to see where things go wrong. Possibly, there is an initialization problem in some other place. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-29 22:15 --- Joost, Do you happen to know at what revision things went bad? As the likely author of the regression, I would be interested to know, so that I can dig us out again. Regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #29 from bergner at vnet dot ibm dot com 2006-11-29 22:23 --- Talking with Andrew on IRC, he said the test case in comment #27 fails for the same reason as the test case in comment #24 (ie, it looks like an artificial decl) and should be fixed with his PTR_PLUS_EXPR work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #8 from jv244 at cam dot ac dot uk 2006-11-29 22:26 --- (In reply to comment #7) > Joost, > > Do you happen to know at what revision things went bad? I'm afraid I don't... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/30023] New: optimize static constructors into initialized data
The attached test case involves a global object with class type and a constructor that just copies values from its arguments into instance variables. It would be nice if GCC would recognize this case and generate an initialized-data object instead of a global constructor invocation. (In this particular example, the entire object could then go into .rodata; but the optimization would be beneficial even for objects that can't.) -- Summary: optimize static constructors into initialized data Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
[Bug c++/30023] optimize static constructors into initialized data
--- Comment #1 from zackw at panix dot com 2006-11-29 23:15 --- Created an attachment (id=12710) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12710&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
[Bug c++/30023] optimize static constructors into initialized data
--- Comment #2 from zackw at panix dot com 2006-11-29 23:16 --- Created an attachment (id=12711) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12711&action=view) code generated from test case by gcc 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
[Bug c++/30023] optimize static constructors into initialized data
--- Comment #3 from zackw at panix dot com 2006-11-29 23:16 --- Created an attachment (id=12712) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12712&action=view) optimal assembly for this test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
[Bug c++/30023] optimize static constructors into initialized data
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-29 23:22 --- *** This bug has been marked as a duplicate of 4131 *** *** This bug has been marked as a duplicate of 4131 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-11-29 23:22 --- *** Bug 30023 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug target/29945] ICE in simplify_subreg with simple code in libgfortran
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-29 23:31 --- The patch is testing right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
[Bug target/24598] Need to support odcctools and its ablity to use --prefix and libtool
-- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-31 18:58:47 |2006-11-29 23:48:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24598
[Bug target/30024] New: [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf
sh-elf compiler segfaults with a null argument for emit_move_insn when compiling gcc.c-torture/compile/2804-1.c with -O1. The gdb backtrace is #0 emit_move_insn (x=0xb7c89e20, y=0x0) at ../../ORIG/trunk/gcc/expr.c:3275 #1 0x08262d94 in rest_of_handle_life () at ../../ORIG/trunk/gcc/flow.c:1560 #2 0x083d3eaa in execute_one_pass (pass=0x85f70e0) at ../../ORIG/trunk/gcc/passes.c:871 Thus the problem occurs in rest_of_handle_life 1560emit_move_insn (param.retval, 1561CONST0_RTX (GET_MODE (param.retval))); where param.retval is (reg:CDI 174) and CONST0_RTX (CDImode) is NULL on this target. -- Summary: [4.3 Regression] segfault with gcc.c- torture/compile/2804-1.c on sh-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
Re: [Bug target/30024] New: [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf
> > sh-elf compiler segfaults with a null argument for emit_move_insn > when compiling gcc.c-torture/compile/2804-1.c with -O1. I get this also for SPU-elf with gcc.c-torture/compile/2804-1.c at -O3 -fomit-frame-pointer -funroll-loops. Thanks, Andrew Pinski
[Bug target/30024] [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf
--- Comment #1 from pinskia at physics dot uc dot edu 2006-11-30 00:03 --- Subject: Re: New: [4.3 Regression] segfault with gcc.c-torture/compile/2804-1.c on sh-elf > > sh-elf compiler segfaults with a null argument for emit_move_insn > when compiling gcc.c-torture/compile/2804-1.c with -O1. I get this also for SPU-elf with gcc.c-torture/compile/2804-1.c at -O3 -fomit-frame-pointer -funroll-loops. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
[Bug rtl-optimization/30024] [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf and spu-elf
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-30 00:03 --- http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg01285.html Oh and it was the same emit_move_insn too. So confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-30 00:03:59 date|| Summary|[4.3 Regression] segfault |[4.3 Regression] segfault |with gcc.c- |with gcc.c- |torture/compile/2804-1.c|torture/compile/2804-1.c |on sh-elf |on sh-elf and spu-elf Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
[Bug rtl-optimization/30024] [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf and spu-elf
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-11-30 00:26 --- Thanks for the confirmation. I've found that #define CONST0_RTX(MODE) (const_tiny_rtx[0][(int) (MODE)]) and const_tiny_rtx[0][(int) CDImode] isn't initialized in init_emit_once. With adding for (mode = GET_CLASS_NARROWEST_MODE (MODE_COMPLEX_INT); mode != VOIDmode; mode = GET_MODE_WIDER_MODE (mode)) const_tiny_rtx[0][(int) mode] = gen_rtx_raw_CONST_INT (mode, 0); to init_emit_once, the segfault went away, though I'm not sure whether it makes sense or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
[Bug target/29945] ICE in simplify_subreg with simple code in libgfortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-30 01:06 --- Subject: Bug 29945 Author: pinskia Date: Thu Nov 30 01:05:58 2006 New Revision: 119348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119348 Log: 2006-11-29 Andrew Pinski <[EMAIL PROTECTED]> PR target/29945 * config/spu/spu.md (extend_compare): New pattern. (extend_compare): Change to expand and use the above pattern. 2006-11-29 Andrew Pinski <[EMAIL PROTECTED]> PR target/29945 * gcc.c-torture/compile/pr29945.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr29945.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/spu/spu.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
[Bug target/29945] ICE in simplify_subreg with simple code in libgfortran
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-30 01:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
[Bug fortran/29387] ICE on character array function of variable length
--- Comment #11 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29387
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
r118220 | pault | 2006-10-30 22:03:24 -0800 (Mon, 30 Oct 2006) | 29 lines
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have
a specific case for EXPR_VARIABLE and, in default, build an ss
to call gfc_conv_expr_descriptor for array expressions..
PR fortran/29490
* trans-expr.c (gfc_set_interface_mapping_bounds): In the case
that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor
values for it and GFC_TYPE_ARRAY_UBOUND.
PR fortran/29641
* trans-types.c (gfc_get_derived_type): If the derived type
namespace has neither a parent nor a proc_name, set NULL for
the search namespace.
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* gfortran.dg/intrinsic_actual_2.f90: New test.
PR fortran/29490
* gfortran.dg/actual_array_interface_1.f90: New test.
PR fortran/29641
* gfortran.dg/used_types_11.f90: New test.
r118221 | rguenth | 2006-10-31 01:08:11 -0800 (Tue, 31 Oct 2006) | 12 lines
2006-10-31 Richard Guenther <[EMAIL PROTECTED]>
* config/i386/i386.md (asindf2, asinsf2, asinxf2, acosdf2,
acossf2, acosxf2, log1psf2, log1pdf2, log1pxf2, ilogbsi2,
expsf2, expdf2, expxf2, exp10sf2, exp10df2, exp10xf2,
exp2sf2, exp2df2, exp2xf2, expm1df2, expm1sf2, expm1xf2,
ldexpdf3, ldexpsf3, ldexpxf3, rintxf2, rintdf2, rintsf2,
lrounddi2, lroundsi2, floorxf2, floordf2, floorsf2,
lfloordi2, lfloorsi2, ceilxf2, ceildf2, ceilsf2,
btruncxf2, btruncdf2, btruncsf2): Conditionalize expansion on
!optimize_size.
Modified:
branches/fixed-point/ (props changed)
branches/fixed-point/gcc/ChangeLog
branches/fixed-point/gcc/config/i386/i386.md
branches/fixed-point/gcc/fortran/ChangeLog
branches/fixed-point/gcc/fortran/trans-expr.c
branches/fixed-point/gcc/fortran/trans-intrinsic.c
branches/fixed-point/gcc/fortran/trans-types.c
branches/fixed-point/gcc/testsuite/ChangeLog
Propchange: branches/fixed-point/
('svnmerge-integrated' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug fortran/29641] [4.1/4.2/4.3 regression] ICE in gfc_get_derived_type
--- Comment #6 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29641
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
r118220 | pault | 2006-10-30 22:03:24 -0800 (Mon, 30 Oct 2006) | 29 lines
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have
a specific case for EXPR_VARIABLE and, in default, build an ss
to call gfc_conv_expr_descriptor for array expressions..
PR fortran/29490
* trans-expr.c (gfc_set_interface_mapping_bounds): In the case
that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor
values for it and GFC_TYPE_ARRAY_UBOUND.
PR fortran/29641
* trans-types.c (gfc_get_derived_type): If the derived type
namespace has neither a parent nor a proc_name, set NULL for
the search namespace.
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* gfortran.dg/intrinsic_actual_2.f90: New test.
PR fortran/29490
* gfortran.dg/actual_array_interface_1.f90: New test.
PR fortran/29641
* gfortran.dg/used_types_11.f90: New test.
r118221 | rguenth | 2006-10-31 01:08:11 -0800 (Tue, 31 Oct 2006) | 12 lines
2006-10-31 Richard Guenther <[EMAIL PROTECTED]>
* config/i386/i386.md (asindf2, asinsf2, asinxf2, acosdf2,
acossf2, acosxf2, log1psf2, log1pdf2, log1pxf2, ilogbsi2,
expsf2, expdf2, expxf2, exp10sf2, exp10df2, exp10xf2,
exp2sf2, exp2df2, exp2xf2, expm1df2, expm1sf2, expm1xf2,
ldexpdf3, ldexpsf3, ldexpxf3, rintxf2, rintdf2, rintsf2,
lrounddi2, lroundsi2, floorxf2, floordf2, floorsf2,
lfloordi2, lfloorsi2, ceilxf2, ceildf2, ceilsf2,
btruncxf2, btruncdf2, btruncsf2): Conditionalize expansion on
!optimize_size.
Modified:
branches/fixed-point/ (props changed)
branches/fixed-point/gcc/ChangeLog
branches/fixed-point/gcc/config/i386/i386.md
branches/fixed-point/gcc/fortran/ChangeLog
branches/fixed-point/gcc/fortran/trans-expr.c
branches/fixed-point/gcc/fortran/trans-intrinsic.c
branches/fixed-point/gcc/fortran/trans-types.c
branches/fixed-point/gcc/testsuite/ChangeLog
Propchange: branches/fixed-point/
('svnmerge-integrated' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29641
[Bug fortran/29490] internal compiler error: in fold_binary, at fold-const.c:8239
--- Comment #9 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29490
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
r118220 | pault | 2006-10-30 22:03:24 -0800 (Mon, 30 Oct 2006) | 29 lines
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have
a specific case for EXPR_VARIABLE and, in default, build an ss
to call gfc_conv_expr_descriptor for array expressions..
PR fortran/29490
* trans-expr.c (gfc_set_interface_mapping_bounds): In the case
that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor
values for it and GFC_TYPE_ARRAY_UBOUND.
PR fortran/29641
* trans-types.c (gfc_get_derived_type): If the derived type
namespace has neither a parent nor a proc_name, set NULL for
the search namespace.
2006-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/29387
* gfortran.dg/intrinsic_actual_2.f90: New test.
PR fortran/29490
* gfortran.dg/actual_array_interface_1.f90: New test.
PR fortran/29641
* gfortran.dg/used_types_11.f90: New test.
r118221 | rguenth | 2006-10-31 01:08:11 -0800 (Tue, 31 Oct 2006) | 12 lines
2006-10-31 Richard Guenther <[EMAIL PROTECTED]>
* config/i386/i386.md (asindf2, asinsf2, asinxf2, acosdf2,
acossf2, acosxf2, log1psf2, log1pdf2, log1pxf2, ilogbsi2,
expsf2, expdf2, expxf2, exp10sf2, exp10df2, exp10xf2,
exp2sf2, exp2df2, exp2xf2, expm1df2, expm1sf2, expm1xf2,
ldexpdf3, ldexpsf3, ldexpxf3, rintxf2, rintdf2, rintsf2,
lrounddi2, lroundsi2, floorxf2, floordf2, floorsf2,
lfloordi2, lfloorsi2, ceilxf2, ceildf2, ceilsf2,
btruncxf2, btruncdf2, btruncsf2): Conditionalize expansion on
!optimize_size.
Modified:
branches/fixed-point/ (props changed)
branches/fixed-point/gcc/ChangeLog
branches/fixed-point/gcc/config/i386/i386.md
branches/fixed-point/gcc/fortran/ChangeLog
branches/fixed-point/gcc/fortran/trans-expr.c
branches/fixed-point/gcc/fortran/trans-intrinsic.c
branches/fixed-point/gcc/fortran/trans-types.c
branches/fixed-point/gcc/testsuite/ChangeLog
Propchange: branches/fixed-point/
('svnmerge-integrated' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29490
[Bug fortran/30025] New: Standard F77 entry point failed
The following code works with g77 but the executable from gfortran yields segmentation fault program test_entry real a(10) a(1) = 999. call x call y(a,10) stop end subroutine x real a(n) write(6,*)'Hello World from subroutine x' return entry y(a,n) call foo(a(1)) end subroutine foo(a) real a write(6,*)'Hello World from entry y ',a return end -- Summary: Standard F77 entry point failed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: elizabeth dot l dot yip at boeing dot com GCC build triplet: ../gcc/configure --prefix=/var/tmp/gfortran- 20061114/irun --enab GCC host triplet: Dell 670 SUSE 9.3 GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30025
[Bug fortran/30025] Standard F77 entry point failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal GCC build triplet|../gcc/configure -- | |prefix=/var/tmp/gfortran- | |20061114/irun --enab| GCC host triplet|Dell 670 SUSE 9.3 | Summary|Standard F77 entry point|Standard F77 entry point |failed |failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30025
[Bug fortran/30025] Standard F77 entry point failed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-30 03:02 --- I think this is a dup of bug 25818. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25818 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30025
[Bug c++/30019] g++ did not issue a warning when it (IMO) could have
--- Comment #1 from bangerth at dealii dot org 2006-11-30 03:22 --- The point is that the temporary isn't unused: you call operator=(char*) on it. The compiler can't know if that has any side effects that you may intend to have happen... -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30019
[Bug c++/29993] typdef declaration of cv-qualified function in class
--- Comment #2 from bangerth at dealii dot org 2006-11-30 03:24 ---
Confirmed. PR 6628 is indeed fixed, but it appears as if it only has an effect
for typedefs outside class declarations:
-
typedef int ptr1() const; // no error
void foo ()
{
typedef int ptr2() const; // no error
}
class C
{
typedef int ptr3() const; // error
void bar ()
{
typedef int ptr4() const; // no error
}
};
-
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc:10: error: ‘const’ and ‘volatile’ function
specifiers on ‘ptr3’ invalid in type declaration
It appears as if Doug's fix for PR 6628 isn't quite complete...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org,
||dgregor at cs dot indiana
||dot edu
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-30 03:24:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2006-11-30 03:32 --- to_write_subrecord = 0 have_written = 0 to_write_subrecord = 0 have_written = 0 to_write_subrecord = 0 have_written = 0 to_write_subrecord = 0 have_written = 0 ad infinitum Now I wonder if the patch applied correctly. I will be checking that, but we definitely are broken here. I will keep at it. I did find some gcc warnings on comparing signed and unsigned integers so I cast those. To no effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug middle-end/30026] New: useless stack movement
There is no reason to be moving %esp in this function.
$ cat cc.c
typedef unsigned long size_t;
extern void *memcpy (void *__restrict, const void *__restrict, size_t);
char *foo1(char*buf){
short tmp2;
int tmp4;
*buf++ = 42;
tmp2=0xfeed;
memcpy(buf,&tmp2,2);
buf += 2;
tmp4 = 0x12345678;
memcpy(buf,&tmp4,4);
buf += 4;
tmp4 = 0x12345678;
memcpy(buf,&tmp4,4);
buf += 4;
return buf;
}
$ gcc -m32 -fomit-frame-pointer -mregparm=3 -O2 -S cc.c
$ cat cc.s
.file "cc.c"
.text
.p2align 4,,15
.globl foo1
.type foo1, @function
foo1:
subl$16, %esp
movb$42, (%eax)
movw$-275, 1(%eax)
movl$305419896, 3(%eax)
movl$305419896, 7(%eax)
addl$11, %eax
addl$16, %esp
ret
.size foo1, .-foo1
.ident "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)"
.section.note.GNU-stack,"",@progbits
$
--
Summary: useless stack movement
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30026
[Bug middle-end/30017] [4.3 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-30 04:18 --- This is obvious what caused it: +2006-11-28 Jan Hubicka <[EMAIL PROTECTED]> + + * builtins.c: Include tree-flow.h. + (fold_builtin_memory_op): Be more aggressive on converting memcpy to + assignment; convert memmove to memcpy for sizes greater than 1 where + alignment of operands prohibit the partial overlap. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jh at suse dot cz Component|c++ |middle-end Summary|ICE in cp_expr_size, at |[4.3 Regression] ICE in |cp/cp-objcp-common.c:101|cp_expr_size, at cp/cp- ||objcp-common.c:101 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug rtl-optimization/30024] [4.3 Regression] segfault with gcc.c-torture/compile/20000804-1.c on sh-elf and spu-elf
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-30 04:29 --- (In reply to comment #3) > Thanks for the confirmation. Well I am a maintainer of the SPU port so I really care about the failures and how ever weird the testcase :). > and const_tiny_rtx[0][(int) CDImode] isn't initialized in > init_emit_once. With adding > > for (mode = GET_CLASS_NARROWEST_MODE (MODE_COMPLEX_INT); >mode != VOIDmode; >mode = GET_MODE_WIDER_MODE (mode)) > const_tiny_rtx[0][(int) mode] = gen_rtx_raw_CONST_INT (mode, 0); > > to init_emit_once, the segfault went away, though I'm not sure > whether it makes sense or not. I have to look into this more to figure out why we are getting a non concat for the complex mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #16 from lucier at math dot purdue dot edu 2006-11-30 04:36 --- I now get a segfault when trying this with the current 4.2.0 branch: [descartes:~/Desktop] lucier% time /pkgs/gcc-4.2.0-64-test/bin/gcc -mcpu=970 -m64 -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -bundle -flat_namespace -undefined suppress -I/usr/local/Gambit-C/include/ -ftime-report -fmem-report all.i gcc: unrecognized option '-no-cpp-precomp' all.c: In function '___H__20_all_2e_o1': all.c:132856: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. 2100.522u 139.425s 49:12.72 75.8% 0+0k 0+13io 0pf+0w running gdb with it gives no more information. Some details: The STAGE1 compiler was host=powerpc64-darwin and target=powerpc64-darwin: [descartes:~/programs/gcc/4.2.0] gcc-test% /pkgs/gcc-4.2.0/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.8.0 Configured with: ../configure --with-gmp=/pkgs/gmp-4.2.1 --with-mpfr=/pkgs/gmp-4.2.1 --prefix=/pkgs/gcc-4.2.0 --enable-languages=c --disable-checking Thread model: posix gcc version 4.2.0 20061021 (prerelease) This was the compiler that segfaulted: (gdb) [descartes:~/Desktop] lucier% /pkgs/gcc-4.2.0-64-test/bin/gcc -v Using built-in specs. Target: powerpc64-apple-darwin8.8.0 Configured with: ../configure --build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0 --target=powerpc64-apple-darwin8.8.0 --enable-languages=c --prefix=/pkgs/gcc-4.2.0-64-test --with-gmp=/pkgs/gmp-4.2.1-64/ --with-mpfr=/pkgs/gmp-4.2.1-64/ Thread model: posix gcc version 4.2.0 20061129 (prerelease) [descartes:~/programs/gcc/4.2.0] gcc-test% cat gcc/BASE-VER 4.2.0 [descartes:~/programs/gcc/4.2.0] gcc-test% cat gcc/DATESTAMP 20061129 [descartes:~/programs/gcc/4.2.0] gcc-test% cat LAST_UPDATED Wed Nov 29 17:51:48 EST 2006 Wed Nov 29 22:51:48 UTC 2006 (revision 119334M) [descartes:~/programs/gcc/4.2.0] gcc-test% gdb -v GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin". A full bootstrap was done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #17 from dberlin at gcc dot gnu dot org 2006-11-30 04:54 --- Subject: Re: Inordinate compile times on large routines On 30 Nov 2006 04:36:05 -, lucier at math dot purdue dot edu <[EMAIL PROTECTED]> wrote: > > > --- Comment #16 from lucier at math dot purdue dot edu 2006-11-30 04:36 > --- > I now get a segfault when trying this with the current 4.2.0 branch: > > [descartes:~/Desktop] lucier% time /pkgs/gcc-4.2.0-64-test/bin/gcc -mcpu=970 > -m64 -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno > -fschedule-insns2 > -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC > -fno-common -bundle -flat_namespace -undefined suppress > -I/usr/local/Gambit-C/include/ -ftime-report -fmem-report all.i > gcc: unrecognized option '-no-cpp-precomp' > all.c: In function '___H__20_all_2e_o1': > all.c:132856: internal compiler error: Bus error > Please submit a full bug report, > with preprocessed source if appropriate It shouldn't crash, but i'm still finishing the patch to not make it take a ridiculous amount of time, which will need to be applied to the 4.2 branch. Should be done this week (I sent a preview to the mailing list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2006-11-30 06:25 --- Good News. I did not have a clean apply of the patch. I reverted everything and started over. There was one part of the patch I had to manually apply before and I must have messed it up. Now everything works great on X86-64 FreeBSD tests. There are two warnings in transfer.c for comparison of signed and unsigned types that need to get cleaned up. Right around line 649 IIRC. With that, this patch is ready to submit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #10 from uros at gcc dot gnu dot org 2006-11-30 06:55 --- Subject: Bug 29852 Author: uros Date: Thu Nov 30 06:54:47 2006 New Revision: 119356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119356 Log: PR target/29852 * config/i386/i386.md (*truncxfsf2_mixed, *truncxfdf2_mixed): Enable insn patterns for TARGET_80387. (*truncxfsf2_i387, *truncxfdf2_i387): Remove. (*truncxfsf2_i387_1): Rename to *truncxfsf2_i387. (*truncxfdf2_i387_1): Rename to *truncxfdf2_i387. (fmod3, remainder3): Enable expaders for SSE math. Generate truncxf2 insn patterns for strict SSE math. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #11 from ubizjak at gmail dot com 2006-11-30 07:17 --- Fixed, by intriducing x87 helpers. Let's see those benchmarks fly again ;) -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||11/msg02000.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #9 from burnus at gcc dot gnu dot org 2006-11-30 07:36 --- (In reply to comment #7) > Do you happen to know at what revision things went bad? The example program, I extracted (comment #6), actually crashes here with - gfortran 4.1.2 20061115 - gcc-Version 4.2.0 20061006 - gcc-Version 4.2.0 20060910 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30025] Standard F77 entry point failed
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-11-30 07:41:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30025
