[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2

2008-10-06 Thread jakub at gcc dot gnu dot org


--- 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.

2008-10-06 Thread suckfish at ihug dot co dot nz
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

2008-10-06 Thread dominiq at lps dot ens dot fr


--- 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

2008-10-06 Thread paolo dot carlini at oracle dot com


--- 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

2008-10-06 Thread paolo dot carlini at oracle dot com


--- 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

2008-10-06 Thread dennis dot wassel at googlemail dot com


--- 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

2008-10-06 Thread joseph at codesourcery dot com


--- 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

2008-10-06 Thread Denis

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

2008-10-06 Thread gcc at jme dot de
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

2008-10-06 Thread kloedej at knmi dot nl
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

2008-10-06 Thread dennis dot wassel at googlemail dot com
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

2008-10-06 Thread nickc at redhat dot com


--- 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)

2008-10-06 Thread dominiq at lps dot ens dot fr
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)

2008-10-06 Thread dominiq at lps dot ens dot fr


--- 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

2008-10-06 Thread dominiq at lps dot ens dot fr
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

2008-10-06 Thread jakub at gcc dot gnu dot org
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

2008-10-06 Thread krebbel at gcc dot gnu dot org


--- 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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread kargl at gcc dot gnu dot org


--- 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

2008-10-06 Thread jakub at gcc dot gnu dot org


-- 

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

2008-10-06 Thread vmakarov at gcc dot gnu dot org


--- 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

2008-10-06 Thread rguenth at gcc dot gnu dot org


--- 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

2008-10-06 Thread rguenth at gcc dot gnu dot org


--- 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

2008-10-06 Thread Andrew Thomas Pinski



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

2008-10-06 Thread linuxl4 at sohu dot com


--- 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

2008-10-06 Thread jakub at gcc dot gnu dot org


--- 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

2008-10-06 Thread nickc at redhat dot com


--- 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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread nickc at redhat dot com


--- 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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread sherpya at netfarm dot it
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

2008-10-06 Thread nickc at redhat dot com


--- 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

2008-10-06 Thread hjl dot tools at gmail dot com
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

2008-10-06 Thread hjl dot tools at gmail dot com


--- 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

2008-10-06 Thread hjl dot tools at gmail dot com


--- 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

2008-10-06 Thread hjl dot tools at gmail dot com
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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread tkoenig at gcc dot gnu dot org
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

2008-10-06 Thread hjl dot tools at gmail dot com


--- 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

2008-10-06 Thread hjl dot tools at gmail dot com


--- 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

2008-10-06 Thread burnus at gcc dot gnu dot org


-- 

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

2008-10-06 Thread burnus at gcc dot gnu dot org


--- 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

2008-10-06 Thread bartoldeman at users dot sourceforge dot net
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

2008-10-06 Thread dannysmith at users dot sourceforge dot net


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2008-10-06 Thread charpour at gnet dot gr
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)

2008-10-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2008-10-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2008-10-06 Thread zlynx at acm dot org
# 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)

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread zlynx at acm dot org


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread joseph at codesourcery dot com


--- 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

2008-10-06 Thread jason at gcc dot gnu dot org


-- 

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

2008-10-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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.

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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.

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread rick at efn dot org
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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread rick at efn dot org


--- 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

2008-10-06 Thread rick at efn dot org


--- 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 `('

2008-10-06 Thread patrick at motec dot com dot au
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 `('

2008-10-06 Thread patrick at motec dot com dot au


--- 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 `('

2008-10-06 Thread patrick at motec dot com dot au


--- 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 `('

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread brian at dessent dot net


--- 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 `('

2008-10-06 Thread patrick at motec dot com dot au


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread sherpya at netfarm dot it


--- 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

2008-10-06 Thread pinskia at gcc dot gnu dot org


--- 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

2008-10-06 Thread jvdelisle at gcc dot gnu dot org


--- 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

2008-10-06 Thread jvdelisle at gcc dot gnu dot org


--- 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

2008-10-06 Thread johnson at cs dot uiuc dot edu


--- 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

2008-10-06 Thread johnson at cs dot uiuc dot edu


--- 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

2008-10-06 Thread jvdelisle at gcc dot gnu dot org


--- 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

2008-10-06 Thread jvdelisle at gcc dot gnu dot org


--- 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

2008-10-06 Thread linuxl4 at sohu dot com


--- 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

2008-10-06 Thread patrick at motec dot com dot au
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

2008-10-06 Thread linuxl4 at sohu dot com


--- 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

2008-10-06 Thread patrick at motec dot com dot au


--- 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

2008-10-06 Thread patrick at motec dot com dot au
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

2008-10-06 Thread patrick at motec dot com dot au


--- 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

2008-10-06 Thread hjl dot tools at gmail dot com
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