[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-06 06:18 ---
This looks like a vectorizer bug to me. Vectorizer creates:
vector void * * vect_pdtds.39;
vector void * * vect_pdtds.34;
vector unsigned char * vect_cst_.33;
...
vect_cst_.33_33 = {dtd, dtd, dtd, dtd};
vect_pdtds.39_34 = (vector void * *) dtds;
vect_pdtds.34_35 = vect_pdtds.39_34;
...
# vect_pdtds.34_36 = PHI vect_pdtds.34_37(9), vect_pdtds.34_35(3)
# ivtmp.40_38 = PHI ivtmp.40_39(9), 0(3)
*vect_pdtds.34_36 = vect_cst_.33_33;
Shouldn't that use VCE instead? void * and unsigned char * certainly have
different alias sets, so storing vect_cst.33 with element type's alias set 3
into dtds variable, which has element alias set 2, doesn't work very well.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37730
[Bug c/37743] New: Bogus printf format warning with __builtin_bswap32.
Code below generates an incorrect warning:
$ gcc -Wall -c temp.c
temp.c:4: warning: format %x expects type unsigned int, but argument 2 has
type unsigned int
$ cat temp.c
int format (const char * f, ...) __attribute__ ((format (printf, 1, 2)));
void bar (unsigned int x)
{
format (%x, __builtin_bswap32 (x));
}
Unless I'm going mad, unsigned int and unsigned int are identical.
Giving an explicit prototype of __builtin_bswap32 works-around.
$ gcc --version ; rpm -q gcc
gcc (GCC) 4.3.2 20080917 (Red Hat 4.3.2-4)
Copyright (C) 2008 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.
gcc-4.3.2-4.x86_64
--
Summary: Bogus printf format warning with __builtin_bswap32.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suckfish at ihug dot co dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-06 08:34 --- Reduced test case: program try_cg0071 type seq integer ia(10) end type TYPE(SEQ) UDA1R type(seq) uda(1) do j1 = 1,10 uda1r%ia(j1) = j1 enddo uda = uda1r UDA(1)%IA(1:9) = UDA(1)%IA(9:1:-1)+1 DO J1 = 1,9 if (UDA1R%IA(10-J1)+1 /= Uda(1)%IA(J1)) call abort() ENDDO end The test does not fail if UDA is not an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug c++/37740] [C++0x] foo f{...} form compiles, but new foo{...} one doesn't
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-06 08:37 --- Let's CC Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37740
[Bug c++/37741] [C++0x] ICE with shared_ptr in initializer-list of new-expression
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-06 08:37 --- Likewise... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37741
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #1 from dennis dot wassel at googlemail dot com 2008-10-06 09:33 --- Created an attachment (id=16464) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16464action=view) example s|.FALSE._C_BOOL|.FALSE.| to cause f951 to hang instead of segfaulting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug c/37745] Segmentation Fault Exception with -O and signed array index
--- Comment #1 from joseph at codesourcery dot com 2008-10-06 11:58 --- Subject: Re: New: Segmentation Fault Exception with -O and signed array index On Mon, 6 Oct 2008, gcc at jme dot de wrote: The following code produces a segmentation fault when compiled with -O. Environment is GCC V4.2.2 (also tested with 4.1.2) on AVR32 Linux target. FSF GCC does not currently support AVR32, so you need to report this bug to whoever you got your modified compiler with that support from. The bug reporting instructions at http://gcc.gnu.org/bugs.html say: What we do not want ... * Bugs in releases or snapshots of GCC not issued by the GNU Project. Report them to whoever provided you with the release -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37745
gcc generates prolog without rsp decrementing, i.e. allocates locals and parameters in free stack without privatising this stack
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,java,ada
--enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp
--disable-libssp --enable-java-awt=gtk --enable-gtk-cairo
--disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
and trying to compile program:
void plus (long * a, long * b)
{
long aa = 10;
long bb =10;
*a += *b + aa + bb;
}
int main (){
long a = 1;
long b = 2;
long *aa = a;
long *bb = b;
plus(aa,bb);
}
##
[EMAIL PROTECTED] gc]$ gcc -S main.c
But code produced for plus function is incorrect:
.file main.c
.text
.globl plus
.type plus, @function
plus:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
## As you can see here it allocates parameters
and autos into stack minus shifts, that is free stack space. I.e. it
didn.t reservation.
movq%rdi, -24(%rbp)
movq%rsi, -32(%rbp)
movq$10, -16(%rbp)
movq$10, -8(%rbp)
movq-24(%rbp), %rax
movq(%rax), %rdx
movq-32(%rbp), %rax
movq(%rax), %rax
addq-16(%rbp), %rax
addq-8(%rbp), %rax
addq%rax, %rdx
movq-24(%rbp), %rax
movq%rdx, (%rax)
leave
ret
.LFE2:
.size plus, .-plus
.globl main
.type main, @function
main:
.LFB3:
pushq %rbp
.LCFI2:
movq%rsp, %rbp
.LCFI3:
# Here it does all correct . firstly reserve
stack frame and then allocates autos and parameters there.
subq$32, %rsp
.LCFI4:
movq$1, -24(%rbp)
movq$2, -32(%rbp)
leaq-24(%rbp), %rax
movq%rax, -16(%rbp)
leaq-32(%rbp), %rax
movq%rax, -8(%rbp)
movq-8(%rbp), %rsi
movq-16(%rbp), %rdi
callplus
leave
ret:
The difference between functions is that main calls other function and
.plus. does not.
In my project I have kernel code that has a function w/o calls
(memcpy) and it is compiled also incorrectly.
And problem is that when *dst = *src executed . pagefault appeared,
this pagefault works on the same stack and rewrites free space, i.e.
rewrites locals of memcpy function.
That results to crash on next read from src.
So probably somebody knows how to solve this problem? I.ve explored
gcc flags and didn.t find anything to solve it.
I.ve also tried another gcc version :
[EMAIL PROTECTED] gc]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
Result is the same.
Thank you in advance,
Denis.
[Bug c/37745] New: Segmentation Fault Exception with -O and signed array index
The following code produces a segmentation fault when compiled with -O.
Environment is GCC V4.2.2 (also tested with 4.1.2) on AVR32 Linux target.
Cross compiled on Cygwin.
With GCC V3.4.4 on Cygwin Target it works correct.
Even when I insert a printf(.); between the if and the for the code works.
static const unsigned aArr[] = {31,28,31};
unsigned Bla(unsigned u8)
{
unsigned u32;
int i,m;
u32=0;
m=u8;
if (m!=0) m--;
//printf(.);
for (i=0; im; i++) u32+=aArr[i];
return u32;
}
int main()
{
Bla(1);
return 0;
}
--
Summary: Segmentation Fault Exception with -O and signed array
index
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at jme dot de
GCC host triplet: Cygwin
GCC target triplet: AVR32 Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37745
[Bug fortran/37746] New: string copy fails, due to changed intent(in) parameter
The following testcase of (I think) valid Fortran90 code, shows a strange error. It copies all characters of a text string except for the first character, which for some unknown reason is replaced by a space. The essential element seems to be the use of the expression len(a)+1 to dimension the size of string b. subroutine copy(a,b) character(len=*),intent(in) :: a character(len=len(a)+1), intent(out) :: b integer :: c print *,inside1: a = [//trim(a)//] b(:)=' ' c=len_trim(a) b(1:c)=a(1:c) print *,inside2: a = [//trim(a)//] print *,len_trim(a)=,c print *,inside: b = [//trim(b)//] end subroutine copy program Test_StrCopy character(len=50) :: a,b a = abcdefg call copy(a,b) end program Test_StrCopy After compiling with: gfortran -o Test_Copy Test_Copy.F90 I get this result: Test_Copy inside1: a = [abcdefg] inside2: a = [ bcdefg] len_trim(a)= 7 inside: b = [ bcdefg] Clearly, the problem seems to be that the intent(in) variable a gets modified, which should never happen. gfortran version used for testing was: gfortran -v Using built-in specs. Target: i586-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20081005 --enable-languages=c,fortran --build=i586-pc-linux-gnu --enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software Thread model: posix gcc version 4.4.0 20081005 (experimental) [trunk revision 140878] (GCC) Best regards, Jos de Kloe, KNMI -- Summary: string copy fails, due to changed intent(in) parameter Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug fortran/37744] New: ICE-on-invalid with ISO_C_BINDING and TYPEs
f951 hangs or segfaults on this invalid piece of code, after printing the correct diagnostic message. The example is very sensitive to changes (even comments or whitespace), causing f951 to either hang, segfault or abort gracefully; this version provokes a segfault. The compiler can be provoked to hang by a) invoking gfortran -march=i686 -mtune=generic pr.F90 b) removing the _C_BOOL modifier from .FALSE. Output is $ gfortran -v pr.F90 Driving: gfortran -v pr.F90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.2/configure --enable-version-specific-runtime-libs -enable-languages=c,c++,fortran --program-suffix=-4.3.2 --with-arch=core2 --with-tune=core2 Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=core2' '-march=core2' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v pr.F90 -mtune=core2 -march=core2 -o /tmp/ccY5rhzV.f95 ignoring nonexistent directory /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=core2' '-march=core2' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 /tmp/ccY5rhzV.f95 -ffree-form -quiet -dumpbase pr.F90 -mtune=core2 -march=core2 -auxbase pr -version -fpreprocessed -fintrinsic-modules-path /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o /tmp/ccWmyykH.s GNU F95 (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64448 pr.F90:22.19: foo%flags(trouble) = .FALSE._C_BOOL 1 Error: Symbol 'trouble' at (1) has no IMPLICIT type f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I plugged f951 into the debugger and it said the culprit is here: gfc_undo_symbols () at gcc/fortran/symbol.c:2180 I cannot follow this any further myself right now. Good hunting! -- Summary: ICE-on-invalid with ISO_C_BINDING and TYPEs Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dennis dot wassel at googlemail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #33 from nickc at redhat dot com 2008-10-06 12:43 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 Hi, http://people.netfarm.it/~sherpya/gcc/info.7z Just a quick check: If you build with -fno-common does the executable then work ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug fortran/37747] New: [4.4 Regression]: Errors when printing real(16)
With revision 140892 I get the following failures in 32 bit mode (but not with
-m64):
FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test
The following reduced test
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
program test
implicit none
integer,parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: x
character(len=20) :: c1, c2
print *, k
x = huge(x)
write (c1,'(G20.10E5)') x
write (c2,'(G20.10E5)') -x
print *, huge(x)/2.0_k
print *, huge(x), nearest(huge(x), -1.0_k)
print *, x, c1
print *, c2
c2(1:1) = ' '
x = tiny(x)
write (c1,'(G20.10E5)') x
write (c2,'(G20.10E5)') -x
print *, tiny(x), nearest(tiny(x), 1.0_k)
print *, x, c1
print *, c2
c2(1:1) = ' '
if (c1 /= c2) call abort
end program test
gives
16
**
**
**
** *
*
0.00
0.00
0.000.00
-0.00
Abort
in 32 bit mode and
16
4.49423283715578976932326297697256183E+0307
8.98846567431157953864652595394512367E+0307
8.98846567431157953864652595394490209E+0307
8.98846567431157953864652595394512367E+0307 0.8988465674E+00308
-0.8988465674E+00308
2.00416836000897277799610805135016205E-0292
2.00416836000897277799610805135020213E-0292
2.00416836000897277799610805135016205E-0292 0.2004168360E-00291
-0.2004168360E-00291
in 64 bit mode.
--
Summary: [4.4 Regression]: Errors when printing real(16)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug fortran/37747] [4.4 Regression]: Errors when printing real(16)
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-06 13:27 --- I have forgotten to say that revision 140513 is working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug fortran/37748] New: [4.4 Regression]: FAIL: gfortran.dg/random_3.f90
With revision 140892 I get the following failures in 32 and 64 bit modes: FAIL: gfortran.dg/random_3.f90 -O0 execution test FAIL: gfortran.dg/random_3.f90 -O1 execution test FAIL: gfortran.dg/random_3.f90 -O2 execution test FAIL: gfortran.dg/random_3.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/random_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/random_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/random_3.f90 -O3 -g execution test FAIL: gfortran.dg/random_3.f90 -Os execution test and revision 140513 was working. -- Summary: [4.4 Regression]: FAIL: gfortran.dg/random_3.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37748
[Bug fortran/37749] New: ICE on array section with vector subscript
subroutine subr (m, n, a, b, c, d, p) implicit none integer m, n real a(m,n), b(m,n), c(n,n), d(m,n) integer p(n) d = a(:,p) - matmul(b, c) end subroutine implicit none integer i real a(3,2), b(3,2), c(2,2), d(3,2) integer p(2) a = reshape ((/(i, i = 1, 6)/), (/3, 2/)) b = 1 c = 2 p = 2 call subr (3, 2, a, b, c, d, p) if (any (d .ne. reshape ((/(mod (i + 2, 3), i = 1, 6)/), (/3, 2/ call abort end ICEs because a loop bound (loop-to[0]) hasn't been set. -- Summary: ICE on array section with vector subscript Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-10-06 14:07 ---
Just to check whether the propagation of the conflicting hard regs in
ira_flatting really is the main problem I've tried the following patch. With
that patch the ira branch bootstraps on s390x.
Index: gcc/ira-build.c
===
--- gcc/ira-build.c.orig2008-10-06 11:16:39.0 +0200
+++ gcc/ira-build.c 2008-10-06 14:44:57.0 +0200
@@ -2147,7 +2147,7 @@ ira_flattening (int max_regno_before_emi
ira_assert (ALLOCNO_CAP_MEMBER (parent_a) == NULL);
if (ALLOCNO_MEM_OPTIMIZED_DEST (a) != NULL)
mem_dest_p = true;
- if (propagate_p)
+ /* if (propagate_p)*/
{
if (!allocno_propagated_p [ALLOCNO_NUM (parent_a)])
COPY_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (parent_a),
I think one reason why this problem does not occur more often and not on other
targets is that on S/390 r6 is used as argument register but is also call
saved!
The conflict between r52 and hard reg r6 is recorded for an instruction which
loads the argument for a function call. Since such an INSN is most likely more
or less directly followed by a call instruction the missing propagation of
conflicting hard regs is papered over by ira_build_conflicts. This function
always adds the call clobbered registers to the conflict sets of pseudos which
are live across function calls. For r6 on S/390 this does not happen what - at
least to my understanding - reveals the bug in ira_flattening.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 --- $ nm ffmpeg_g.exe |grep ff_cos_16 00dd84e0 B _ff_cos_16 00de04c0 B _ff_cos_16384 except snow and svq1 tests, crashing because of bugs in tree opts on win32 sse code is working fine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug fortran/37746] string copy fails, due to changed intent(in) parameter
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-06 14:47 --- Your code works if you fix the bug. You have two choices program Test_StrCopy character(len=50) :: a character(len=51) :: b a = abcdefg call copy(a,b) end program Test_StrCopy or subroutine copy(a,b) character(len=*), intent(in) :: a character(len=len(a)), intent(out) :: b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
-- 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 |2008-10-06 15:11:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #16 from vmakarov at gcc dot gnu dot org 2008-10-06 15:35 --- Subject: Bug 37535 Author: vmakarov Date: Mon Oct 6 15:34:26 2008 New Revision: 140906 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140906 Log: 2008-10-06 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. * doc/rtx.texi (clobber): Change how RA deals with clobbers. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/rtl.texi trunk/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-06 15:55 --- We need a testcase for this (preprocessed source of opsum.c). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug c/37745] Segmentation Fault Exception with -O and signed array index
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-06 15:59 --- This will invoke for (i=0; i0; i++) which invokes undefined behavior on signed integer overflow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37745
Re: gcc generates prolog without rsp decrementing, i.e. allocates locals and parameters in free stack without privatising this stack
Sent from my iPhone
On Oct 6, 2008, at 5:09 AM, Denis [EMAIL PROTECTED] wrote:
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --
with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-
languages=c,c++,objc,fortran,java,ada --enable-checking=release --
with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-
libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-
multilib --with-slibdir=/lib64 --with-system-zlib --enable-shared --
enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-
system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
and trying to compile program:
void plus (long * a, long * b)
{
long aa = 10;
long bb =10;
*a += *b + aa + bb;
}
int main (){
long a = 1;
long b = 2;
long *aa = a;
long *bb = b;
plus(aa,bb);
}
##
[EMAIL PROTECTED] gc]$ gcc -S main.c
But code produced for plus function is incorrect:
.file main.c
.text
.globl plus
.type plus, @function
plus:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
## As you can see here it allocates
parameters and autos into stack minus shifts, that is free stack
space. I.e. it didn.t reservation.
This is ok as the x86_64 ABI has a red zone. If you are running into a
problem, then your kernel is not following the ABI.
movq%rdi, -24(%rbp)
movq%rsi, -32(%rbp)
movq$10, -16(%rbp)
movq$10, -8(%rbp)
movq-24(%rbp), %rax
movq(%rax), %rdx
movq-32(%rbp), %rax
movq(%rax), %rax
addq-16(%rbp), %rax
addq-8(%rbp), %rax
addq%rax, %rdx
movq-24(%rbp), %rax
movq%rdx, (%rax)
leave
ret
.LFE2:
.size plus, .-plus
.globl main
.type main, @function
main:
.LFB3:
pushq %rbp
.LCFI2:
movq%rsp, %rbp
.LCFI3:
# Here it does all correct . firstly
reserve stack frame and then allocates autos and parameters there.
subq$32, %rsp
.LCFI4:
movq$1, -24(%rbp)
movq$2, -32(%rbp)
leaq-24(%rbp), %rax
movq%rax, -16(%rbp)
leaq-32(%rbp), %rax
movq%rax, -8(%rbp)
movq-8(%rbp), %rsi
movq-16(%rbp), %rdi
callplus
leave
ret:
The difference between functions is that main calls other function
and .plus. does not.
In my project I have kernel code that has a function w/o calls
(memcpy) and it is compiled also incorrectly.
And problem is that when *dst = *src executed . pagefault appeared,
this pagefault works on the same stack and rewrites free space, i.e.
rewrites locals of memcpy function.
That results to crash on next read from src.
So probably somebody knows how to solve this problem? I.ve explored
gcc flags and didn.t find anything to solve it.
I.ve also tried another gcc version :
[EMAIL PROTECTED] gc]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
Result is the same.
Thank you in advance,
Denis.
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #2 from linuxl4 at sohu dot com 2008-10-06 16:21 --- I really don't know how to make the preprocessed source ,since no include path is given. the Makefile only give the message such as: CC ../../../../src/mpi/coll/opsum.c I will study it.someone maybe can help me do this. mpich2-1.1.0a1.tar.gz can be download from http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-06 16:31 --- If you read the URL gcc printed ( http://gcc.gnu.org/bugs.html ), you'll know how to produce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #35 from nickc at redhat dot com 2008-10-06 16:43 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 Hi sherpya, --- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 --- $ nm ffmpeg_g.exe |grep ff_cos_16 00dd84e0 B _ff_cos_16 00de04c0 B _ff_cos_16384 except snow and svq1 tests, crashing because of bugs in tree opts on win32 sse code is working fine As I suspected. The PE/COFF file format does not provide for specifying the alignment of commons. Hmm, I wonder if gcc should complain if it finds aligned commons with COFF backends or if we should try to generate a GNU extension to the COFF format. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #36 from sherpya at netfarm dot it 2008-10-06 17:14 --- so how with -fno-common can make aligned work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #37 from nickc at redhat dot com 2008-10-06 17:24 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 Hi, so how with -fno-common can make aligned work? Hang on - I thought that you had said that when ffmpeg_g.exe was built with -fno-common that it worked, modulo some (completely separate) tree optimization bugs. Is that not right ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #38 from sherpya at netfarm dot it 2008-10-06 17:27 --- yes alignment works, and even my test align program with 4.2 without patches gives correct alignment to local and global symbols Local Aligned 16: 0 Local Aligned 32: 0 Global Aligned 16: 0 Global Aligned 32: 0 16 - 265986.00 - 32 - 132994.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug tree-optimization/37750] New: a lot of crashes with tree optimizations on mingw
while testing ffmpeg compiled with gcc 4.3.3 from 4.3 trunk I got a lot of crashes especially in snow encoding testcase by using: -fno-tree-dominator-opts -fno-tree-vrp -fno-dce -fno-tree-ch I get no crashes gcc 4.4 has same problems, I've already filled a bug about tree-ch, that corrupts the stack on win32 (looks like it's related to alloca()) -- Summary: a lot of crashes with tree optimizations on mingw Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #39 from nickc at redhat dot com 2008-10-06 18:16 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 yes alignment works, and even my test align program with 4.2 without patches gives correct alignment to local and global symbols OK, so when you said: so how with -fno-common can make aligned work? did you really mean: so how without -fno-common can make aligned work? In which case the answer is - I do not know. The problem is that the PE/COFF file format does not support aligned commons. We could try to create an extension to the format to support them, but that would be non-standard. Another possibility would be to turn any common symbol with an alignment attribute into a weak symbol instead. This would work (I think, I have not tried it), provided that there are no other definitions of the same symbol with a different size. Which would possibly cause problems with FORTRAN programs but it is unlikely to be an issue with C/C++ programs. Another possibility is to modify the linker so that when it is placing common symbols into the .bss section of the output executable every symbol is aligned to the maximum alignment specified for any of the .bss sections of any input object file. This would probably waste huge amounts of space in the .bss section (for large programs anyway) but it ought to work. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37751] New: TARGET_USE_HIMODE_FIOP is unused
On x86 backend, TARGET_USE_HIMODE_FIOP is never used. -- Summary: TARGET_USE_HIMODE_FIOP is unused Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37751
[Bug target/24764] TARGET_MEMORY_MISMATCH_STALL is never used
--- Comment #2 from hjl dot tools at gmail dot com 2008-10-06 18:40 --- It is used in http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg00769.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24764
[Bug target/24766] Unused TARGET_DECOMPOSE_LEA
--- Comment #2 from hjl dot tools at gmail dot com 2008-10-06 18:41 --- It is removed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24766
[Bug target/37752] New: TARGET_USE_SIMODE_FIOP is unused
TARGET_USE_SIMODE_FIOP is unused in x86 backend. -- Summary: TARGET_USE_SIMODE_FIOP is unused Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37752
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #40 from sherpya at netfarm dot it 2008-10-06 18:54 --- I mean that with -fno-common alignment works, even with non patched 4.2, my question is due to the fact that it's not so clear for me what no-common does and adding -fno-common what are side effects? do using something like dummy or nops in bss section does something wrong? at this point a forced alignment to 16 wouldn't be such a problem for the space wasted, at least this can avoid problems with sse code (16 bytes) and 3dnow (8 bytes) gcc may need to disable sse code on mingw/cygwin or at least avoid implicit vectorizations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libfortran/37753] New: [4.4 Regression] Convert=BIG_ENDIAN reverses character
From http://gcc.gnu.org/ml/fortran/2008-10/msg00045.html : $ cat foo.f90 character(len=16) :: string, string2 string='BIG_ENDIAN' open(unit=13,form='unformatted',file='gftest.dat',convert='big_endian',status='UNKNOWN') write(13) string close(13) end $ gfortran foo.f90 $ ./a.out $ od -t x1 -t a gftest.dat 000 00 00 00 10 20 20 20 20 20 20 4e 41 49 44 4e 45 nul nul nul dle sp sp sp sp sp sp N A I D N E 020 5f 47 49 42 00 00 00 10 _ G I B nul nul nul dle 030 -- Summary: [4.4 Regression] Convert=BIG_ENDIAN reverses character Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
[Bug target/37752] TARGET_USE_SIMODE_FIOP is unused
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-06 19:34 --- It is fixed by TARGET_USE_MODEMODE_FIOP. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37752
[Bug target/37751] TARGET_USE_HIMODE_FIOP is unused
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-06 19:34 --- It is used by TARGET_USE_MODEMODE_FIOP. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37751
[Bug fortran/37749] ICE on array section with vector subscript
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.2 4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-10-06 19:47:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug fortran/37746] string copy fails, due to changed intent(in) parameter
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-06 19:53 --- I think the true bug is that -fbounds-check misses the problem. NAG f95 prints at run time: CHARACTER actual arg LEN=50 shorter than dummy arg LEN=51 Program terminated by fatal error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug libfortran/37754] New: READ I/O Performance regression from 4.3 to 4.4
GFortran is slower with I/O than g77 was (I think that was known already).
But 4.4 is even slower than 4.3 in certain cases, e.g.:
a simple program to count lines:
countlines.f
---
PROGRAM countlines
C Count lines on stdin
I=0
DO
READ(*,*,END=1)
I=I+1
ENDDO
1CONTINUE
PRINT *,I
END PROGRAM
-
Create a file with 10,000,000 empty lines, for instance like this:
$ python -c import sys; sys.stdout.write('\n'*1000) temp
Using: gcc version 4.4.0 20081005 (experimental) [trunk revision 140878] (GCC):
$ gfortran -O countlines.f
$ time ./a.out temp
1000
real0m3.745s
user0m3.740s
sys 0m0.004s
Using: gcc version 4.3.1 (Debian 4.3.1-9)
1000
real0m2.603s
user0m2.588s
sys 0m0.016s
Using: g77 (gcc version 3.4.6 (Debian 3.4.6-6))
1000
real0m0.733s
user0m0.728s
sys 0m0.004s
--
Summary: READ I/O Performance regression from 4.3 to 4.4
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bartoldeman at users dot sourceforge dot net
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #41 from dannysmith at users dot sourceforge dot net 2008-10-06 20:18 --- (In reply to comment #35) As I suspected. The PE/COFF file format does not provide for specifying the alignment of commons. Hmm, I wonder if gcc should complain if it finds aligned commons with COFF backends or if we should try to generate a GNU extension to the COFF format. Aligned commons are not part of the PE COFF spec and AFAICT neither MASM nor NASM provide a way to specify aligned commons. I am afraid that a GNU extension will cause object incompatibility, so it would it need to be a non-default option. We already have -fno-common __attribute__((no_common)) #pragma gcc optimize (no_common) G++ already puts commons in .bss Perhaps a new option -fno_large_common that applies -fcommon only to objects with align = 4 bytes? A warning would be useful in any case. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Summary|bootstrap broken with core |[4.4 Regression] bootstrap |gcc gcc-4.2.x |broken with core gcc gcc- ||4.2.x Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/37755] New: Mistaken Segmentation fault
GCC Version: 4.2.3
Host: Ubuntu 8.04
When I compile the following code:
#include stdio.h
typedef struct person {
char name[40];
int age;
} Person;
static Person make_person(void);
int main(void) {
printf(%s\n, make_person().name);
return 0;
}
static Person make_person(void) {
static Person p = { alexander, 18 };
return p;
}
I get a false warning:
warning: format %s expects type char *, but argument 2 has type char[40]
and when I execute the file I get a segmentation fault.
If I use: printf(%s\n, make_person().name[0]);
everything works as expected and the output alexander is printed
--
Summary: Mistaken Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charpour at gnet dot gr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755
[Bug fortran/37747] [4.4 Regression]: Errors when printing real(16)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug fortran/37748] [4.4 Regression]: FAIL: gfortran.dg/random_3.f90
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37748
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:17 --- No other target has this issue except Win32. I am going to say mingw support for alloca is broken somehow. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Component|tree-optimization |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug libfortran/37753] [4.4 Regression] Convert=BIG_ENDIAN reverses character
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
[Bug c/37756] New: ICE building object file with -O3 and -combine
# gcc *.i -combine -O3 -c -o udns.o dia-submit/udns_init.c: In function dns_set_srch_internal: dia-submit/udns_init.c:47: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1698 Because it only appears to happen when building with multiple input files, I have attached a tar of .i files that reproduce the problem (the udns async DNS resolver library actually). I have observed this ICE on i386 and x86_64 and IA64 builds of GCC 4.3.2. -- Summary: ICE building object file with -O3 and -combine Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zlynx at acm dot org GCC host triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug fortran/37747] [4.4 Regression]: Errors when printing real(16)
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:18 --- Was this fixed by: 2008-10-02 David Edelsohn [EMAIL PROTECTED] * config/rs6000/rs6000.c (USE_FP_FOR_ARG_P): Revert TARGET_DOUBLE_FLOAT, TARGET_SINGLE_FLOAT. (function_arg_advance): Condition on TARGET_DOUBLE_FLOAT, TARGET_SINGLE_FLOAT. Revert SCALAR_FLOAT_MODE_P condition. (function_arg): Condition on TARGET_DOUBLE_FLOAT, TARGET_SINGLE_FLOAT. (rs6000_function_value): Revert TARGET_DOUBLE_FLOAT, TARGET_SINGLE_FLOAT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug c/37755] Mistaken Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:25 --- I don't get a seg fault on ppc but I do on x86. It works correctly for the C++ front-end where the array decays into a pointer. The warning is also bogus but it shows what the issue is really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755
[Bug c/37756] ICE building object file with -O3 and -combine
--- Comment #1 from zlynx at acm dot org 2008-10-06 21:25 --- Created an attachment (id=16465) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16465action=view) Gzipped Tar of .i files for bug reproduction -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug c/37755] Mistaken Segmentation fault
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:25 --- 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 |2008-10-06 21:25:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755
[Bug c/37755] Mistaken Segmentation fault
--- Comment #3 from joseph at codesourcery dot com 2008-10-06 21:39 --- Subject: Re: New: Mistaken Segmentation fault On Mon, 6 Oct 2008, charpour at gnet dot gr wrote: printf(%s\n, make_person().name); make_person().name is a non-lvalue array, so it only decays to a pointer for C99, not for C90. If you use -std=c99/-std=gnu99 then the program works. The program does not, however, have defined behavior for C99, only for C1x. In C99 the lifetime of the array ends at the next sequence point, before the call to printf. In C1x it instead ends at the end of the evaluation of the containing full expression, which is the call to printf. I do not believe any changes to GCC are needed to implement this particular C1x requirement, since GCC discards information about variables lifetimes smaller than a function for gimplification and tree optimizations that may change those lifetimes, so it will in practice treat the lifetime as being anywhere it cannot show the temporary not to be live. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755
[Bug c++/37376] [4.4 Regression] No standard mangling for char16/32_t yet
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-04 20:09:11 |2008-10-06 21:48:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37376
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|READ I/O Performance|[4.4 Regression] READ I/O |regression from 4.3 to 4.4 |Performance regression from ||4.3 to 4.4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 21:53 --- The failure started with r132589 Though it pushed the code limit up on the functions inside insn-automata.o. I wonder if we could get a way to disable and enable some scheduling for the first stage where we only need a few of them. -- 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 |2008-10-06 21:53:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:55 --- DEF_GCC_BUILTIN(BUILT_IN_BSWAP32, bswap32, BT_FN_UINT32_UINT32, ATTR_CONST_NOTHROW_LIST) This is caused by the fact __builtin_bswap32 uses uintSItype instead of the normal unsignedint types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:56 --- DEF_FUNCTION_TYPE_1 (BT_FN_UINT32_UINT32, BT_UINT32, BT_UINT32) DEF_PRIMITIVE_TYPE (BT_UINT32, uint32_type_node) Instead of using: DEF_PRIMITIVE_TYPE (BT_UINT, unsigned_type_node) But we need to use the 32bit type here instead of unsigned_type really -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug c/37757] New: When -Os is enabled, gcc generates a loop where there is none
When -Os is enabled, gcc generates a loop where there is none. gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) Command line: gcc -Os -c -Wa,-alh,-L test.c /tmp/test.opt.lis # Removing -Os removes bug No warnings, errors or output files: http://www.efn.org/~rick/pub/test.i http://www.efn.org/~rick/pub/test.c -- Summary: When -Os is enabled, gcc generates a loop where there is none Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rick at efn 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=37757
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #2 from sherpya at netfarm dot it 2008-10-06 22:34 --- this problem started with 4.3, 4.3.2 on debian linux hasn't these problems -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug c/37757] When -Os is enabled, gcc generates a loop where there is none
--- Comment #1 from rick at efn dot org 2008-10-06 22:36 --- Created an attachment (id=16466) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16466action=view) Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
[Bug c/37757] When -Os is enabled, gcc generates a loop where there is none
--- Comment #2 from rick at efn dot org 2008-10-06 22:37 --- Created an attachment (id=16467) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16467action=view) i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
[Bug inline-asm/37758] New: Assembler failure: Error: syntax error; found `,' but expected `('
powerpc-eabispe-gcc -v -save-temps -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include -nostdinc -fsingle-precision-constant -mabi=no-spe -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -std=gnu99 -fno-stack-protector -Wno-variadic-macros -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -fno-omit-frame-pointer -DDEBUG -g -Wsign-compare -Werror-implicit-function-declaration -include tomcrypt_opts.h -I../tfm/src/headers -I../ -Wall -W -Wshadow -Isrc/headers -O3 -funroll-loops -fomit-frame-pointer -c -o src/mont/fp_montgomery_reduce.o src/mont/fp_montgomery_reduce.c Using built-in specs. Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.3.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c --disable-nls --disable-multilib --disable-werror --without-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp Thread model: single gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/include' '-I/home/patrick/src/e7/prex/usr/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-include' 'tomcrypt_opts.h' '-I../tfm/src/headers' '-I../' '-Wall' '-W' '-Wshadow' '-Isrc/headers' '-O3' '-funroll-loops' '-fomit-frame-pointer' '-c' '-o' 'src/mont/fp_montgomery_reduce.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -E -quiet -nostdinc -v -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include -I../tfm/src/headers -I../ -Isrc/headers -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -DDEBUG -include tomcrypt_opts.h src/mont/fp_montgomery_reduce.c -mabi=no-spe -ansi -std=gnu99 -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -Wall -W -Wshadow -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -funroll-loops -fomit-frame-pointer -fworking-directory -Os -O3 -fpch-preprocess -o fp_montgomery_reduce.i ignoring duplicate directory src/headers #include ... search starts here: #include ... search starts here: /home/patrick/src/e7/prex /home/patrick/src/e7/prex/include /home/patrick/src/e7/prex/usr/include ../tfm/src/headers ../ End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/include' '-I/home/patrick/src/e7/prex/usr/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-include' 'tomcrypt_opts.h' '-I../tfm/src/headers' '-I../' '-Wall' '-W' '-Wshadow' '-Isrc/headers' '-O3' '-funroll-loops' '-fomit-frame-pointer' '-c' '-o' 'src/mont/fp_montgomery_reduce.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -fpreprocessed fp_montgomery_reduce.i -quiet -dumpbase fp_montgomery_reduce.c -mabi=no-spe -ansi -auxbase-strip src/mont/fp_montgomery_reduce.o -gdwarf-2 -g -Os -O3 -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -Wall -W -Wshadow -ansi -std=gnu99 -version -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -funroll-loops -fomit-frame-pointer -o fp_montgomery_reduce.s GNU C (GCC) version 4.3.2 (powerpc-eabispe) compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c30b16423d0b6addaa52d5eb1153852d src/mont/fp_montgomery_reduce.c: In function 'fp_montgomery_reduce': src/mont/fp_montgomery_reduce.c:521: warning: matching constraint does not allow a register src/mont/fp_montgomery_reduce.c:526: warning: matching constraint does not allow a register src/mont/fp_montgomery_reduce.c:521: warning: matching constraint does not allow a register src/mont/fp_montgomery_reduce.c:526: warning: matching constraint does not allow a register src/mont/fp_montgomery_reduce.c:551: warning: matching constraint does not allow a register src/mont/fp_montgomery_reduce.c:551: warning: matching
[Bug inline-asm/37758] Assembler failure: Error: syntax error; found `,' but expected `('
--- Comment #1 from patrick at motec dot com dot au 2008-10-06 23:06 --- Created an attachment (id=16468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16468action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
[Bug inline-asm/37758] Assembler failure: Error: syntax error; found `,' but expected `('
--- Comment #2 from patrick at motec dot com dot au 2008-10-06 23:10
---
The problem appears to be that the loop
for (; y pa; y++) {
asm( mullw16,%3,%4 \n\t
mulhwu 17,%3,%4 \n\t
addc 16,16,%0 \n\t
addze17,17 \n\t
lwz 18,%1 \n\t
addc 16,16,18 \n\t
addze%0,17 \n\t
stw 16,%1 \n\t
:=r(cy),=m(_c[0]):0(cy),r(mu),r(tmpm[0]),1(_c[0]):16, 17,
18,%cc); ++tmpm;;
++_c;
}
is being unrolled, resulting in
# 521 src/mont/fp_montgomery_reduce.c 1
mullw16,28,0
mulhwu 17,28,0
addc 16,16,11
addze17,17
lwz 18,4(29)
addc 16,16,18
addze11,17
stw 16,4(29)
# 0 2
.L335:
lwzx 5,31,3
# 521 src/mont/fp_montgomery_reduce.c 1
mullw16,28,5
mulhwu 17,28,5
addc 16,16,11
addze17,17
lwz 18,29,3
addc 16,16,18
addze11,17
stw 16,29,3
# 0 2
addi 3,3,4
and so on...
where the lwz 18,29,3 is not understood by the assembler.
I am currently working around this problem by making the variable _c volatile,
which prevents the loop from being unrolled.
--
patrick at motec dot com dot au changed:
What|Removed |Added
Known to fail||4.3.0 4.3.1 4.3.2
Known to work||4.1.1 4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
[Bug inline-asm/37758] Assembler failure: Error: syntax error; found `,' but expected `('
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 23:12 --- You either need to require [reg+offset] or use stw%U0%X0 for the m constraint. Likewise for lwz. The other question is why are you using inline-asm in the first place for the load/stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 4.3.1 4.3.2 | Known to work|4.1.1 4.1.2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #42 from brian at dessent dot net 2008-10-06 23:29 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 When you are comparing gcc 4.2 to current trunk, are you keeping the linker (binutils) version the same? As mentioned in comment 6, the linker behavior changed recently which results in a different default alignment of the .bss segment which could explain the difference. IMHO, we should just have gcc automatically enable -fno-common on PE if SSE is enabled. That's what the MS tools do, AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug inline-asm/37758] Assembler failure: Error: syntax error; found `,' but expected `('
--- Comment #4 from patrick at motec dot com dot au 2008-10-06 23:31 --- I'm not personally responsible for this code, it is part of the LibTomMath library. Changing the constraint to either =o or =g appears to resolve the problem (will need to test). -- patrick at motec dot com dot au changed: What|Removed |Added Known to fail||4.3.0 4.3.1 4.3.2 Known to work||4.1.1 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
[Bug target/37757] When -Os is enabled, gcc generates a loop where there is none
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 23:37 --- Hmm, works with -march=i668 as that enables ifcvt. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #43 from sherpya at netfarm dot it 2008-10-07 01:32 --- binutils 2.18.91.20080917 on both there are changes for the local alignment in the gas code but gcc does not use them without my attached gcc_align_fix.diff patch (not sure 100%) newer binutils are not working well on mingw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-10-07 02:06 --- This still fails after the patch to fix PR 37535 on i386-darwin8.11.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug libfortran/37753] [4.4 Regression] Convert=BIG_ENDIAN reverses character
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-10-07 02:54 --- Thomas, any ideas and do you have time to investigate this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-10-07 02:55 --- I am a bit stacked up, but I will explore this one a bit. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-07 02:55:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug target/33120] Large module object files when declare arrays on Mac OSX
--- Comment #3 from johnson at cs dot uiuc dot edu 2008-10-07 02:58 --- Created an attachment (id=16469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16469action=view) fruit.f90, illustrates huge .o file, requires fruit_util.f90 I think I have a testcase that shows this bug. I was trying to compile FRUIT on my Mac and discovered that fruit.o was 450MB! I am attaching fruit.f90 and fruit_util.f90. I had to modify fruit.f90 a little bit to make it compile; I just added a pair of matching parentheses to two lines. So I figured I should attach the files instead of pointing to them. Ralph Johnson - [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug target/33120] Large module object files when declare arrays on Mac OSX
--- Comment #4 from johnson at cs dot uiuc dot edu 2008-10-07 02:58 --- Created an attachment (id=16470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16470action=view) fruit_util.f90, needed to compile fruit.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-07 03:58 --- strace shows no difference in number of system calles between 4.3 and 4.4. gprof has some interesting things to see. With 4.4: % cumulative self self total time seconds secondscalls ms/call ms/call name 30.93 0.54 0.54 data_transfer_init 8.67 0.69 0.15 fflush 8.09 0.83 0.14 get_external_unit 6.94 0.95 0.12 finalize_transfer 6.65 1.06 0.12 next_char 6.36 1.17 0.11 fd_read 3.47 1.23 0.06 memcpy 2.60 1.28 0.05 _gfortran_st_read 2.31 1.32 0.04 fd_sfree With 4.3: % cumulative self self total time seconds secondscalls ms/call ms/call name 26.25 0.42 0.42 data_transfer_init 12.50 0.62 0.20 fflush 9.38 0.77 0.15 finalize_transfer 6.25 0.87 0.101 100.00 100.00 MAIN__ 6.25 0.97 0.10 get_external_unit 5.94 1.07 0.10 next_char 4.69 1.14 0.08 _gfortran_st_read 2.81 1.19 0.05 fd_alloc_r_at 2.50 1.23 0.04 _gfortrani_library_start 2.19 1.26 0.04 _gfortran_st_read_done I will try some of my more aggressive I/O tests and report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-07 04:25 --- With the following test program I created a file to read useing a write in place of the read. program testio implicit none integer :: i, k real :: x real(kind=8) :: y complex :: c character(27) :: a integer, parameter :: n = 100 x = 3.14159 y = exp(1.0) c = complex(x,y) a = abcdefghijklmnopqrstuvwxyz1 open(10,form=formatted) do i=1,n read(10, '(i10,1x,f7.5,1x,f12.10,1x,a27,1x,2f12.8)') k, x, y, a, c end do close(10, status=keep) end program testio With 4.4: $ time ./a.out real0m9.307s user0m9.238s sys 0m0.063s With 4.3: $ time ./a.out real0m8.167s user0m8.113s sys 0m0.034s That's about 13% slowdown in formatted reads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #4 from linuxl4 at sohu dot com 2008-10-07 05:02 --- Created an attachment (id=16471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16471action=view) the preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug target/37759] New: powerpc option -mno-spe still generates SPE instructions
powerpc-eabispe-gcc -I../ -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include -nostdinc -fsingle-precision-constant -mno-spe -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -std=gnu99 -fno-stack-protector -Wno-variadic-macros -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -fno-omit-frame-pointer -DDEBUG -g -Wsign-compare -Werror-implicit-function-declaration -v -save-temps -MD -MT core_thread.o -MP -MF .core_thread.d -c -o core_thread.o core_thread.c Using built-in specs. Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.3.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c --disable-nls --disable-multilib --disable-werror --without-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp Thread model: single gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-I../' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/include' '-I/home/patrick/src/e7/prex/usr/include' '-nostdinc' '-fsingle-precision-constant' '-mno-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'core_thread.o' '-MP' '-MF' '.core_thread.d' '-c' '-o' 'core_thread.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -E -quiet -nostdinc -v -I../ -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include -MD core_thread.d -MF .core_thread.d -MP -MT core_thread.o -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -DDEBUG core_thread.c -mno-spe -ansi -std=gnu99 -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -fworking-directory -Os -fpch-preprocess -o core_thread.i #include ... search starts here: #include ... search starts here: ../ /home/patrick/src/e7/prex /home/patrick/src/e7/prex/include /home/patrick/src/e7/prex/usr/include End of search list. COLLECT_GCC_OPTIONS='-I../' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/include' '-I/home/patrick/src/e7/prex/usr/include' '-nostdinc' '-fsingle-precision-constant' '-mno-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'core_thread.o' '-MP' '-MF' '.core_thread.d' '-c' '-o' 'core_thread.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -fpreprocessed core_thread.i -quiet -dumpbase core_thread.c -mno-spe -ansi -auxbase-strip core_thread.o -gdwarf-2 -g -Os -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -ansi -std=gnu99 -version -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -o core_thread.s GNU C (GCC) version 4.3.2 (powerpc-eabispe) compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c30b16423d0b6addaa52d5eb1153852d COLLECT_GCC_OPTIONS='-I../' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/include' '-I/home/patrick/src/e7/prex/usr/include' '-nostdinc' '-fsingle-precision-constant' '-mno-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'core_thread.o' '-MP' '-MF' '.core_thread.d' '-c' '-o' 'core_thread.o' /home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.3.2/../../../../powerpc-eabispe/bin/as -mppc -mspe -me500 -many -V -Qy -o core_thread.o core_thread.s GNU assembler version 2.18 (powerpc-eabispe) using BFD version (GNU Binutils) 2.18
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #5 from linuxl4 at sohu dot com 2008-10-07 05:07 --- gcc -O3 -march=pentium4 -c opsum.c fails. instead, gcc -O2 -march=pentium4 -c opsum.c or gcc -O3 -march=i686 -c opsum.c pass. -- linuxl4 at sohu dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug target/37759] powerpc option -mno-spe still generates SPE instructions
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:07 --- Created an attachment (id=16472) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16472action=view) preprocessed source after compiling, evstdd and evldd instructions are emitted even though the -mno-spe flag was specified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
[Bug middle-end/37760] New: internal compiler error: in extract_insn, at recog.c:1990
powerpc-eabispe-gcc -I../include -I/home/patrick/src/e7/prex/dev/include -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -nostdinc -fsingle-precision-constant -mcpu=common -mfloat-gprs=single -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -std=gnu99 -fno-stack-protector -Wno-variadic-macros -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -fno-omit-frame-pointer -DDEBUG -g -Wsign-compare -Werror-implicit-function-declaration -v -save-temps -MD -MT ecu_table.o -MP -MF .ecu_table.d -c -o ecu_table.o ecu_table.c Using built-in specs. Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.3.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c --disable-nls --disable-multilib --disable-werror --without-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp Thread model: single gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-I../include' '-I/home/patrick/src/e7/prex/dev/include' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mcpu=common' '-mfloat-gprs=single' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'ecu_table.o' '-MP' '-MF' '.ecu_table.d' '-c' '-o' 'ecu_table.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -E -quiet -nostdinc -v -I../include -I/home/patrick/src/e7/prex/dev/include -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -MD ecu_table.d -MF .ecu_table.d -MP -MT ecu_table.o -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -DDEBUG ecu_table.c -mcpu=common -mfloat-gprs=single -ansi -std=gnu99 -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -fworking-directory -Os -fpch-preprocess -o ecu_table.i #include ... search starts here: #include ... search starts here: ../include /home/patrick/src/e7/prex/dev/include /home/patrick/src/e7/prex /home/patrick/src/e7/prex/usr/include /home/patrick/src/e7/prex/include End of search list. COLLECT_GCC_OPTIONS='-I../include' '-I/home/patrick/src/e7/prex/dev/include' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mcpu=common' '-mfloat-gprs=single' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'ecu_table.o' '-MP' '-MF' '.ecu_table.d' '-c' '-o' 'ecu_table.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -fpreprocessed ecu_table.i -quiet -dumpbase ecu_table.c -mcpu=common -mfloat-gprs=single -ansi -auxbase-strip ecu_table.o -gdwarf-2 -g -Os -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -ansi -std=gnu99 -version -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -o ecu_table.s GNU C (GCC) version 4.3.2 (powerpc-eabispe) compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c30b16423d0b6addaa52d5eb1153852d ecu_table.c: In function 'find_index_f32': ecu_table.c:63: error: unrecognizable insn: (insn 104 103 105 13 ecu_table.c:43 (set (reg:CCFP 193) (unspec:CCFP [ (reg:CCFP 191) (reg:CCFP 192) ] 1018)) -1 (nil)) ecu_table.c:63: internal compiler error: in extract_insn, at recog.c:1990 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in extract_insn, at recog.c:1990 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3
[Bug middle-end/37760] internal compiler error: in extract_insn, at recog.c:1990
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:49 --- Created an attachment (id=16473) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16473action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37760
[Bug c++/37761] New: [4.4 Regression]: Revision 140916 caused libstdc++ failures
Revision 140916: http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00117.html caused +FAIL: abi/demangle/abi_examples/20.cc execution test +FAIL: abi/demangle/abi_text/02.cc execution test +FAIL: abi/demangle/regression/cw-16.cc execution test -- Summary: [4.4 Regression]: Revision 140916 caused libstdc++ failures Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37761
