[Bug rtl-optimization/36321] Optimization higher or equal to -O2 produce wrong code

2008-05-24 Thread nightstrike at gmail dot com


--- Comment #5 from nightstrike at gmail dot com  2008-05-25 06:54 ---
I am regtesting it now.  Note that it will take a very long time to complete
(several days).

This does apply to 4.3 and 4.4


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug bootstrap/36324] New: Bootstrap comparison failure with BOOT_CFLAGS=-pg (trunk r135848)

2008-05-24 Thread oliver dot kellogg at eads dot com
Trying to create a compiler that can be run in gprof,

$ ../../SOURCES/gcc/configure --prefix=/opt/gnat/fsf/wavefront \
  --enable-languages=c,c++,ada --enable-debug 
$ make BOOT_CFLAGS='-pg'

rm -f stage_current
make[3]: Leaving directory `/usr/src/packages/BUILD/build-gcc'
Comparing stages 2 and 3
warning: ./cc1plus-checksum.o differs
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./c-pch.o differs
./c-objc-common.o differs
./c-decl.o differs
./c-semantics.o differs
./c-dump.o differs
./attribs.o differs
./c-cppbuiltin.o differs
./c-pretty-print.o differs
./c-parser.o differs
./c-omp.o differs
./c-lang.o differs
./c-typeck.o differs
./c-lex.o differs
./c-common.o differs
./build/genautomata.o differs
./build/genmodes.o differs
./build/gcov-iov.o differs
./build/gengtype-lex.o differs
./build/genflags.o differs
./build/genemit.o differs
./build/rtl.o differs
./build/genopinit.o differs
./build/read-rtl.o differs
./build/genextract.o differs
./build/errors.o differs
./build/ggc-none.o differs
./build/genattr.o differs
./build/gencodes.o differs
./build/genconstants.o differs
./build/genmddeps.o differs
./build/print-rtl.o differs
./build/vec.o differs
./build/genconditions.o differs
./build/genoutput.o differs
./build/gengenrtl.o differs
./build/gencondmd.o differs
./build/gensupport.o differs
./build/gencheck.o differs
./build/genattrtab.o differs
./build/genpreds.o differs
./build/genpeep.o differs
./build/genconfig.o differs
./build/gengtype-parse.o differs
./build/min-insn-modes.o differs
./build/gengtype.o differs
./build/genrecog.o differs
./c-gimplify.o differs
./dummy-checksum.o differs
./c-format.o differs
./c-ppoutput.o differs
./stub-objc.o differs
./tree-mudflap.o differs
./c-aux-info.o differs
./tree-browser.o differs
./prefix.o differs
./c-pragma.o differs
./cppdefault.o differs
./c-incpath.o differs
./main.o differs
./c-opts.o differs
./c-convert.o differs
./c-errors.o differs
make[2]: *** [compare] Error 1

Is this supposed to work?
Thanks.


-- 
   Summary: Bootstrap comparison failure with BOOT_CFLAGS=-pg (trunk
r135848)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot kellogg at eads dot com
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36324



[Bug fortran/36323] Inside an interface, gfortran does not know about selected_real_kind

2008-05-24 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2008-05-24 22:49 ---
Your program is invalid

 * * *

   INTERFACE
  FUNCTION F(X) RESULT (FUNCTION_VALUE)
  REAL(REAL_12), INTENT(IN) :: X

Use either:

a)  REAL(SELECTED_REAL_KIND(P=12)), INTENT(IN) :: X

b)  IMPORT :: REAL_12
REAL(REAL_12) ...

c)  IMPORT
REAL(REAL_12) ...

The IMPORT statement (b and c) is part of Fortran 2003.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36323



[Bug fortran/36323] New: Inside an interface, gfortran does not know about selected_real_kind

2008-05-24 Thread MyForumUsage at gmail dot com
FUNCTION AFUN (F, A) &
RESULT (RESULT)

IMPLICIT NONE
INTEGER, PARAMETER :: REAL_12 = SELECTED_REAL_KIND(P=12)

   INTERFACE
  FUNCTION F(X) RESULT (FUNCTION_VALUE)
  REAL(REAL_12), INTENT(IN) :: X! REAL_12 not
recognized
  REAL(REAL_12) :: FUNCTION_VALUE   ! REAL_12 not
recognized
  END FUNCTION F
   END INTERFACE

   REAL(REAL_12), INTENT(IN):: A! REAL_12 is
recognized
END FUNCTION AFUN


-- 
   Summary: Inside an interface, gfortran does not know about
selected_real_kind
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MyForumUsage at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36323



[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)

2008-05-24 Thread paulbeard at gmail dot com


--- Comment #6 from paulbeard at gmail dot com  2008-05-24 20:16 ---
(In reply to comment #5)
> GCC is running out of memory.
> 
> Oh. I'll add a swapfile and see how that goes. 
> 

It still just grinds until I kill the process. I have since worked around this
problem by installing the package, rather than building from source: I will
leave the same information over the GNOME bugtracker. If I can provide any
other information, let me know. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294



[Bug preprocessor/36320] Required diagnosis of syntax error missed

2008-05-24 Thread tromey at gcc dot gnu dot org


--- Comment #2 from tromey at gcc dot gnu dot org  2008-05-24 18:04 ---
Testing a patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-24 16:21:05 |2008-05-24 18:04:32
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320



[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code

2008-05-24 Thread ubizjak at gmail dot com


--- Comment #4 from ubizjak at gmail dot com  2008-05-24 17:54 ---
(In reply to comment #3)

> Sorry, I missed to install the new compiler :}
> Yes, it works, assembler looks now fine.

Can you please regtest the patch on your target?

BTW: Is this a regression for 4.3 and 4.4?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers

2008-05-24 Thread jaydub66 at gmail dot com


--- Comment #8 from jaydub66 at gmail dot com  2008-05-24 17:52 ---
I have a patch which can handle this test case, see
http://gcc.gnu.org/ml/fortran/2008-05/msg00296.html

It's not complete yet, and some details need to be fixed, but the basic
functionality is there. I hope it can be committed to trunk quite soon.

Cheers,
Janus


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580



[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code

2008-05-24 Thread ktietz at gcc dot gnu dot org


--- Comment #3 from ktietz at gcc dot gnu dot org  2008-05-24 17:01 ---
(In reply to comment #1)

Sorry, I missed to install the new compiler :}

Yes, it works, assembler looks now fine.
Thanks, Kai

.file   ""
.section .rdata,"dr"
LC0:
.ascii "%s %s\12\0"
.text
.p2align 4,,15
.globl _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushq   %rbp
movq%rsp, %rbp
movq%rsi, -16(%rbp)
movq%rdi, -8(%rbp)
movq%rbx, -24(%rbp)
subq$64, %rsp
call_strlen
leal15(%rax,%rax,2), %ecx
subq$32, %rsp
leaq32(%rsp), %rsi
movslq  %ecx,%rdi
leaq30(%rdi), %rdx
andq$-16, %rdx
movq%rdx, %rax
call___chkstk
movl$121, %edx
leaq32(%rsp), %rbx
leal-1(%rcx), %eax
movl$2021161080, (%rsi)
movb$0, 4(%rsi)
movq%rbx, %rcx
movslq  %eax,%r8
call_memset
leaqLC0(%rip), %rcx
movq%rbx, %r8
movq%rsi, %rdx
movb$0, -1(%rbx,%rdi)
call_printf
movq-24(%rbp), %rbx
movq-16(%rbp), %rsi
movq-8(%rbp), %rdi
leave
ret
.def_strlen;.scl2;  .type   32; .endef
.def_memset;.scl2;  .type   32; .endef
.def_printf;.scl2;  .type   32; .endef


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code

2008-05-24 Thread ktietz at gcc dot gnu dot org


--- Comment #2 from ktietz at gcc dot gnu dot org  2008-05-24 16:36 ---
(In reply to comment #1)
> Can you try this patch:
> 
> Index: i386.md
> ===
> --- i386.md (revision 135849)
> +++ i386.md (working copy)
> @@ -19707,7 +19707,7 @@
> (set_attr "length" "5")])
> 
>  (define_insn "allocate_stack_worker_64"
> -  [(set (match_operand:DI 0 "register_operand" "=a")
> +  [(set (match_operand:DI 0 "register_operand" "+a")
> (unspec_volatile:DI [(match_dup 0)] UNSPECV_STACK_PROBE))
> (set (reg:DI SP_REG) (minus:DI (reg:DI SP_REG) (match_dup 0)))
> (clobber (reg:DI R10_REG))
> 

I tried it. There is no difference.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug preprocessor/36320] Required diagnosis of syntax error missed

2008-05-24 Thread tromey at gcc dot gnu dot org


--- Comment #1 from tromey at gcc dot gnu dot org  2008-05-24 16:21 ---
Confirmed.  This seems like a weird design to me, but my reading of the
standard text agrees with yours.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-24 16:21:05
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320



[Bug fortran/36322] New: ICE with PROCEDURE using a complicated interface

2008-05-24 Thread burnus at gcc dot gnu dot org
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4

The full program should be checked after fixing this problem.

==28722== Invalid read of size 4
==28722==at 0x407597: gfc_is_compile_time_shape (array.c:2184)
==28722==by 0x46B11B: resolve_symbol (resolve.c:6811)
==28722==by 0x477326: traverse_ns (symbol.c:3014)
==28722==by 0x4659DF: resolve_types (resolve.c:9179)


module other_fun
   use ISO_C_BINDING
   implicit none
   character, allocatable, save :: my_message(:)
   abstract interface
  function abstract_fun(x)
 use ISO_C_BINDING
 import my_message
 implicit none
 integer(C_INT) x(:)
 character(size(my_message),C_CHAR) abstract_fun(size(x))
  end function abstract_fun
   end interface
   contains
subroutine get_funloc(x)
  procedure(abstract_fun):: x
end subroutine get_funloc
end module other_fun


-- 
   Summary: ICE with PROCEDURE using a complicated interface
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322



[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code

2008-05-24 Thread ubizjak at gmail dot com


--- Comment #1 from ubizjak at gmail dot com  2008-05-24 16:03 ---
Can you try this patch:

Index: i386.md
===
--- i386.md (revision 135849)
+++ i386.md (working copy)
@@ -19707,7 +19707,7 @@
(set_attr "length" "5")])

 (define_insn "allocate_stack_worker_64"
-  [(set (match_operand:DI 0 "register_operand" "=a")
+  [(set (match_operand:DI 0 "register_operand" "+a")
(unspec_volatile:DI [(match_dup 0)] UNSPECV_STACK_PROBE))
(set (reg:DI SP_REG) (minus:DI (reg:DI SP_REG) (match_dup 0)))
(clobber (reg:DI R10_REG))


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point

2008-05-24 Thread steven at gcc dot gnu dot org


--- Comment #13 from steven at gcc dot gnu dot org  2008-05-24 15:37 ---
This happens again on PPC.  No test case yet.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967



[Bug rtl-optimization/36321] New: Optimization higher or eqaul to -O2 produce wrong code

2008-05-24 Thread ktietz at gcc dot gnu dot org
For the i386 stack probing feature there is a non-standard argument register
%eax used for internal __chkstk call. If the code is translate with gcc with
optimization level one or less, code is fine. For -O2 and higher, the argument
%eax for __chkstk is optimized out.

The following source is a short test-case for this:

#include 
#include 
#include 
#include 

void foo(char *str)
{
  int len = strlen ("ABCDE");
  int len2 = len + strlen (str);
  char *a = (char *) alloca(len);
  char *b = (char *) alloca(len2*3);

  memset (a,'x',len-1); a[len-1]=0;
  memset (b,'y',len2*3-1); b [len2*3-1]=0;
  printf ("%s %s\n", a, b);
}

For optimization -O2 the following assembler is produced (I mark the bad code
by  !):

.file   ""
.section .rdata,"dr"
LC0:
.ascii "%s %s\12\0"
.text
.p2align 4,,15
.globl _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushq   %rbp
movq%rsp, %rbp
movq%rsi, -16(%rbp)
movq%rdi, -8(%rbp)
movq%rbx, -24(%rbp)
subq$64, %rsp
call_strlen
subq$32, %rsp
!   leal15(%rax,%rax,2), %ecx
leaq32(%rsp), %rsi
movslq  %ecx,%rdi
call___chkstk
movl$121, %edx
leaq32(%rsp), %rbx
leal-1(%rcx), %eax
movl$2021161080, (%rsi)
movb$0, 4(%rsi)
movq%rbx, %rcx
movslq  %eax,%r8
call_memset
leaqLC0(%rip), %rcx
movq%rbx, %r8
movq%rsi, %rdx
movb$0, -1(%rbx,%rdi)
call_printf
movq-24(%rbp), %rbx
movq-16(%rbp), %rsi
movq-8(%rbp), %rdi
leave
ret
.def_strlen;.scl2;  .type   32; .endef
.def_memset;.scl2;  .type   32; .endef
.def_printf;.scl2;  .type   32; .endef

For optimization -O1 correct assembly is produced:
.file   ""
.section .rdata,"dr"
LC0:
.ascii "%s %s\12\0"
.text
.globl _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushq   %rbp
movq%rsp, %rbp
movq%rbx, -24(%rbp)
movq%rsi, -16(%rbp)
movq%rdi, -8(%rbp)
subq$96, %rsp
movq%rcx, %rdi
movl$0, %eax
movq$-1, %rcx
repne scasb
notq%rcx
leaq32(%rsp), %rsi
leal12(%rcx,%rcx,2), %ecx
movslq  %ecx,%rdi
leaq30(%rdi), %rax
andq$-16, %rax
call___chkstk
leaq32(%rsp), %rbx
movl$2021161080, (%rsi)
movb$0, 4(%rsi)
subl$1, %ecx
movslq  %ecx,%r8
movl$121, %edx
movq%rbx, %rcx
call_memset
movb$0, -1(%rbx,%rdi)
movq%rbx, %r8
movq%rsi, %rdx
leaqLC0(%rip), %rcx
call_printf
movq-24(%rbp), %rbx
movq-16(%rbp), %rsi
movq-8(%rbp), %rdi
leave
ret
.def_memset;.scl2;  .type   32; .endef
.def_printf;.scl2;  .type   32; .endef


-- 
   Summary: Optimization higher or eqaul to -O2 produce wrong code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: 86_64-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321



[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c

2008-05-24 Thread steven at gcc dot gnu dot org


--- Comment #7 from steven at gcc dot gnu dot org  2008-05-24 14:31 ---
I have found a test case for the issue mentioned in comment #4. And it comes
from gcc itself:

static int *free_phinodes[10 - 2]; /* was 'tree' */
static unsigned long free_phinode_count;
void
init_phinodes (void)
{
  int i;
  for (i = 0; i < 10 - 2; i++)
free_phinodes[i] = ((void *)0);
  free_phinode_count = 0
}

When compiling this on powerpc-unknown-elf with r135815 and with the options
"-O2 -fdump-rtl-gcse1-slim", I get the following RTL at the end of the GCSE
pass:

   37 NOTE_INSN_BASIC_BLOCK
   36 NOTE_INSN_FUNCTION_BEG
   39 r164:SI=high(`*.LANCHOR0')
   40 r166:SI=r164:SI+low(`*.LANCHOR0')
  REG_DEAD: r164:SI
  REG_EQUAL: `*.LANCHOR0'
   75 r153:SI=r166:SI
  REG_EQUAL: `*.LANCHOR0'
   73 r165:SI=r166:SI+0x20
  REG_DEAD: r167:SI
  REG_EQUAL: const(`*.LANCHOR0'+0x20)
L46:
   42 NOTE_INSN_BASIC_BLOCK
   43 r156:SI=0x0
   44 [r153:SI]=r156:SI
  REG_EQUAL: 0x0
   45 r153:SI=r153:SI+0x4
   71 r157:SI=r166:SI
  REG_EQUAL: `*.LANCHOR0'
   50 r160:CC=cmp(r153:SI,r165:SI)
  REG_EQUAL: cmp(r153:SI,const(`*.LANCHOR0'+0x20))
   51 pc={(r160:CC!=0x0)?L46:pc}
  REG_DEAD: r160:CC
  REG_BR_PROB: 0x222e
   52 NOTE_INSN_BASIC_BLOCK
   56 [r157:SI+0x20]=r156:SI
  REG_DEAD: r157:SI
  REG_DEAD: r156:SI
  REG_EQUAL: 0x0

This is the dump *after* CPROP2, so the post-PRE-GCSE const/copy pass has run. 
Note the REG_EQUAL note on insn 71: "r157:SI=r166:SI {REG_EQUAL:
`*.LANCHOR0'}". This is a reg-reg copy insn, but CPROP2 does not record the
copy.  Instead it records that r157 is equal to the REG_EQUAL note value.  The
result is that CPROP2 fails to copy propagate r166 into insn 56 (where r157
reaches and dies, so the copy propagation would eliminate r157).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503



[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple

2008-05-24 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2008-05-24 11:02 ---
CONFIRM. Due to the missing checking it works with openSUSE's 4.1, 4.2, 4.3;
however, if one studies the source code, it is also wrong in other 4.x besides
4.4. The current test case fails only on systems where c_intptr_t == 8, but it
can easily be modified to show the same problem on c_intptr_t == 4 systems by
changing in

  INTEGER   :: global_length,local_start,local_end,nchnks
END TYPE distributed_vector

INTEGER into INTEGER(8) (which in turn fixes the program in -m64 systems).


The original dump shows the problem:

caininad_scale_distvec ()
integer(kind=8) D.1027;
integer(kind=4) D.1026;
integer(kind=4) D.1025;
D.1023 = &pvazg;
D.1025 = D.1023->local_start;
D.1026 = D.1023->local_end;
D.1027 = D.1026 - D.1025;  // which is integer(8) = integer(4) - integer(4)


D.1023->local_start; and D.1023->local_end; are used in:

  REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-05-24 11:02:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316



[Bug preprocessor/36320] New: Required diagnosis of syntax error missed

2008-05-24 Thread neil at gcc dot gnu dot org
The syntax error in #elif below is not diagnosed with (say) --std=c99
-pedantic-errors.

int z;
#if 1
#elif
#endif

Syntax is:

elif-group:
# elif constant-expression new-line groupopt

and constant expression cannot be empty.  The syntax relaxation of 6.10p4 does
not apply as the group that the #elif lies in (beginning with the #if) is not
skipped.


-- 
   Summary: Required diagnosis of syntax error missed
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320