[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90

2007-04-19 Thread dorit at il dot ibm dot com
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 --- (In reply to comment #4) (In reply to comment #3) But then I wonder why we don't see the same failure on ia64? Because the failing part of the testcase is only done on ilp32 targets: ! { dg-final {

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread burnus at gcc dot gnu dot org
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 --- Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) Well, we do. if (any (Up (AbCdEfGhIjKlM) .ne. (/ABCDEFGHIJKLM/))) stop 'ERROR' compiles

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread Tobias dot Schlueter at physik dot uni-muenchen dot de
--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-04-19 09:08 --- Subject: Re: wrong types in array transfer burnus at gcc dot gnu dot org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 --- Nevertheless, the

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread pault at gcc dot gnu dot org
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-19 10:37 --- (In reply to comment #7) I am completely trapped by the workshop that I am running and have not even managed to do what I promised last night. Realistically, it might have to wait until the weekend. If you can

[Bug middle-end/31631] New: Folding of A (1 B) pessimizes FRE

2007-04-19 Thread rguenth at gcc dot gnu dot org
void foo (int control2, unsigned long *state, int size) { int i; for(i=0; isize; i++) { if (state[i] ((unsigned long) 1 control2)) state[i] ^= ((unsigned long) 1 control2); } } FRE does not recognize the ((unsigned long) 1 control2) redundancy because it looks

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread rguenth at gcc dot gnu dot org
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-19 12:08 --- The patch in http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html makes the testcase ICE because of the type mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608

[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap

2007-04-19 Thread ebotcazou at gcc dot gnu dot org
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19 --- Subject: Bug 29841 Author: ebotcazou Date: Thu Apr 19 12:19:16 2007 New Revision: 123970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123970 Log: PR rtl-optimization/29841 * cfgbuild.c

[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap

2007-04-19 Thread ebotcazou at gcc dot gnu dot org
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19 --- Subject: Bug 29841 Author: ebotcazou Date: Thu Apr 19 12:19:39 2007 New Revision: 123971 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123971 Log: PR rtl-optimization/29841 * cfgbuild.c

[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap

2007-04-19 Thread ebotcazou at gcc dot gnu dot org
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:21 --- Should work now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/31632] New: [4.1 regression]

2007-04-19 Thread jakub at gcc dot gnu dot org
-- Summary: [4.1 regression] Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at

[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values

2007-04-19 Thread jakub at gcc dot gnu dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2007-04-19 12:40 --- struct S { long int l; void *m; }; int foo (struct S *x) { unsigned long a; a = x-l; if (a = ((void *) 0)) x-m = 0; return 0; } ICEs at -O2 on both x86_64-linux and ppc-linux. -- jakub at gcc dot

[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values

2007-04-19 Thread jakub at gcc dot gnu dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2007-04-19 12:56 --- I'd say this is a frontend bug (in all of 4.1/4.2/4.3 at least), it shouldn't have created eq_expr 0x2dff85a0 type boolean_type 0x2e0018f0 _Bool public unsigned QI size integer_cst 0x2dff2660

[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90

2007-04-19 Thread tprince at computer dot org
--- Comment #8 from tprince at computer dot org 2007-04-19 14:35 --- 4.2 branch appears to have the identical problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561

[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values

2007-04-19 Thread jakub at gcc dot gnu dot org
--- Comment #3 from jakub at gcc dot gnu dot org 2007-04-19 14:58 --- Actually a bug in fold-const. -- jakub at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread pault at gcc dot gnu dot org
--- Comment #10 from pault at gcc dot gnu dot org 2007-04-19 15:20 --- (In reply to comment #5) For the record, the problem Richard is pointing out is in the body of the function Up, namely in the expression for MERGE, probably caused by TRANSFER. Duuh! You are right about where the

[Bug fortran/31608] wrong types in array transfer

2007-04-19 Thread rguenth at gcc dot gnu dot org
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-19 15:55 --- It's not blocking me atm as a different patch got accepted which doesn't expose this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608

[Bug fortran/25071] dummy argument larger than actual argument

2007-04-19 Thread burnus at gcc dot gnu dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-19 16:16 --- Analogously for character lengths: program test character(len=10) :: x call foo(x) write(*,*) 'X=',x contains subroutine foo(y) character(len=20)

[Bug c/31633] New: Calling an uninitialized function pointer does not trigger a warning

2007-04-19 Thread carottegcc at therodox dot com
See: % cat gcc-bug.c int foo(void) { int (*bar)(int); return bar(33); } % gcc -c -Wall gcc-bug.c ^ NO WARNING % gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr --b

[Bug c/31633] Calling an uninitialized function pointer does not trigger a warning

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 17:24 --- Use -O1 if you want to find unitialized variables (including function pointers): [pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./cc1 -quiet -W -Wall t5.c -O1 t5.c: In function 'foo': t5.c:4: warning: 'bar' is used

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

2007-04-19 Thread opruz at centrum dot cz
--- Comment #17 from opruz at centrum dot cz 2007-04-19 17:29 --- 4.1.2 -m32 -O2 .L6: movl8(%ebp), %ebx movl4(%edx), %ecx movl-4(%ebx,%eax,4), %ebx movl%ecx, -20(%ebp) cmpl%ecx, %ebx movl%ebx, -16(%ebp) jle

[Bug java/31622] Segment violation in the #8220;toString#8221; method on a mathematical expression

2007-04-19 Thread eduardo dot iniesta at aquiline dot es
--- Comment #3 from eduardo dot iniesta at aquiline dot es 2007-04-19 17:39 --- (In reply to comment #1) Thanks... The exact version is: $ gcj --version gcj (GCC) 4.3.0 20061212 (experimental) ... Are you sure you are using gcj 4.3? I see a SEGV with 4.1 and 4.2. But with 4.3

[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 17:39 --- Fixed by: Author: echristo Date: Wed Apr 18 23:27:51 2007 New Revision: 123960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123960 Log: 2007-04-18 Eric Christopher [EMAIL PROTECTED] *

[Bug target/28623] [4.1/4.2/4.3 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]

2007-04-19 Thread rth at gcc dot gnu dot org
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org

[Bug pch/31634] New: *_SECTION_ASM_OP storage has undocumented constraints

2007-04-19 Thread amylaar at gcc dot gnu dot org
The macros TEXT_SECTION_ASM_OP, DATA_SECTION_ASM_OP, SDATA_SECTION_ASM_OP, READONLY_DATA_SECTION_ASM_OP, CTORS_SECTION_ASM_OP, DTORS_SECTION_ASM_OP, BSS_SECTION_ASM_OP and SBSS_SECTION_ASM_OP are used by varasm.c:init_varasm_once to pass their value to get_unnamed_section; the result of that

[Bug target/31635] New: -mno-vrsave ignored on ppc64

2007-04-19 Thread gcc at breakpoint dot cc
The -mno-vrsave switch as well as the old -mvrsave=no is ignored on 64bit target. Testcase is an empty file. Results with powerpc64-unknown-linux-gnu-gcc -o a.s -c b.c -maltivec -mno-vrsave -S -fverbose-asm -m64 into: # rs6000/powerpc options: -msdata=none .section.toc,aw

[Bug pch/31634] *_SECTION_ASM_OP storage has undocumented constraints

2007-04-19 Thread amylaar at gcc dot gnu dot org
--- Comment #1 from amylaar at gcc dot gnu dot org 2007-04-19 19:27 --- On second thought, the implementation is simpler when NULL is not treated specially. But then there is a slight majority of the uses in the config directory that wants the old behaviour of get_unnamed_section, so

[Bug tree-optimization/31636] New: ICE in GCC 4.2 with dllimport attribute returns

2007-04-19 Thread arcangelpip at hotmail dot com
--disable-multilib --enable-c99 --enable-long-long --enable-sjlj-exceptions --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --enable-libada --enable-boehm-gc Thread model: win32 gcc version 4.2.0 20070419 (prerelease) I have tried to report this using the old thread twice now, but it hasn't

[Bug target/31636] ICE in GCC 4.2 with dllimport attribute returns

2007-04-19 Thread arcangelpip at hotmail dot com
--- Comment #1 from arcangelpip at hotmail dot com 2007-04-19 19:51 --- Forgot to mention, it works the same as before. If the optimisations are removed then it will compile, but if you have -O1 -O2 or -O3 in the command line then it will ICE. Also, if the dllimport is removed then it

[Bug target/31636] ICE in GCC 4.2 with dllimport attribute returns

2007-04-19 Thread arcangelpip at hotmail dot com
--- Comment #2 from arcangelpip at hotmail dot com 2007-04-19 19:55 --- Forgot to mention 2. -_-; memory is getting worse, I'm sure of it. Command line used. With the executable in the path. i686-pc-mingw32-gcc -c -O2 -o test.o test.c --

[Bug c++/31579] [4.3 regression] ICE when compiling attached code

2007-04-19 Thread bangerth at dealii dot org
--- Comment #3 from bangerth at dealii dot org 2007-04-19 20:06 --- Confirmed. This is a regression on at least mainline. I don't have my set of compilers around here to verify if it is also a regression on 4.1 and 4.2.x. It seems to work with 4.0.x. W. -- bangerth at dealii dot

[Bug c++/31596] Internal compiler error (Segmentation fault)

2007-04-19 Thread bangerth at dealii dot org
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:08 --- This appears fixed since gcc 3.4.x. -- bangerth at dealii dot org changed: What|Removed |Added

[Bug c++/31579] [4.3 regression] ICE when compiling attached code

2007-04-19 Thread pinskia at gcc dot gnu dot org
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target

[Bug c++/31597] Unrecognized ambiguity in function overloading

2007-04-19 Thread bangerth at dealii dot org
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:10 --- Fixed since 4.0.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC|

[Bug c++/31579] [4.3 regression] ICE when compiling attached code

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-19 20:15 --- (In reply to comment #3) Confirmed. This is a regression on at least mainline. I don't have my set of compilers around here to verify if it is also a regression on 4.1 and 4.2.x. It seems to work with 4.0.x. I

[Bug fortran/31637] New: warn about implicit conversion causing loss of precision

2007-04-19 Thread vivekrao4 at yahoo dot com
For the program program main implicit none real :: xx double precision :: yy call random_seed() call random_number(yy) xx = yy ! assign double to single print*,yy =,yy print*,xx =,xx end program main g95 -Wall -Wextra says In file xreal_dp.f90:7 xx = yy 1 Warning (140): Implicit

[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor

2007-04-19 Thread pault at gcc dot gnu dot org
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 20:47 --- (In reply to comment #1) This does the trick but I haven't checked against the standard, nor have I regtested. Paul Index: /svn/trunk/gcc/fortran/check.c

[Bug libfortran/30694] minval/maxval with +/-Inf

2007-04-19 Thread tkoenig at gcc dot gnu dot org
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-19 21:03 --- (In reply to comment #14) (In reply to comment #13) The tree stuff is hard, btw. Still trying :-) Tree stuff? Do we generate inline code? We generate inline code for rank 0 minval and minloc, i.e. real

[Bug fortran/31618] backspace intrinsic is not working on an unformatted file

2007-04-19 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-04-19 21:35 --- (In reply to comment #2) Confirming. g77 does not do it right either. :) gfortran 4.1 doesn't get this right either, so at least this isn't a regression. Uff :-) -- tkoenig at gcc dot gnu dot org changed:

[Bug fortran/31637] warn about implicit conversion causing loss of precision

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 --- *** This bug has been marked as a duplicate of 27866 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 --- *** Bug 31637 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/31612] -fsyntax-only documentation is not accurate

2007-04-19 Thread tobi at gcc dot gnu dot org
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-19 22:42 --- module a end module a use a end How are you going to handle this? There's no meaningful syntax checking without also creating modules. One could maybe create the modules in a temporary place? -- tobi at gcc dot

[Bug fortran/31612] -fsyntax-only documentation is not accurate

2007-04-19 Thread fxcoudert at gcc dot gnu dot org
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-19 22:44 --- Simply fixing the doc is also fine with me :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31612

[Bug target/31480] [4.1/4.2 Regression] ICE with -O -fomit-frame-pointer on SH

2007-04-19 Thread kkojima at gcc dot gnu dot org
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-04-20 00:05 --- I've confirmed that the testcase doesn't fail with 3.4 compiler and fails with 4.0, 4.1 and 4.2. Although it doesn't fail with the current trunk compiler, it might be simply latent. The segfault occurs in

[Bug libstdc++/31638] New: [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align

2007-04-19 Thread tbm at cyrius dot com
[ Forwarded from http://bugs.debian.org/382153 This issue has been reported by Margarita Manterola who also provided the testcase ] If you compile the following testcase with -Wcast-align you get a warning on certain architectures, including alpha, arm, hppa, ia64 and sparc. I've verified this

[Bug libstdc++/31638] [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align

2007-04-19 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 00:49 --- I think this is really the same as PR 19495. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638

[Bug fortran/31639] New: [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

2007-04-19 Thread tbm at cyrius dot com
[ forwarded from http://bugs.debian.org/401496 The report and original testcase came from Jonathan Stott. I further reduced it down in size. ] I've confirmed this bug with 4.1.2 20061115 and 4.3.0 20070326. (sid)18753:[EMAIL PROTECTED]: ~/src/t] gfortran -c c.f90 c.f90: In function

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

2007-04-19 Thread brooks at gcc dot gnu dot org
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-20 01:52 --- This is invalid code, since initialization expressions must be constants, and the length of an assumed-length string argument is not a constant. Regardless, we shouldn't be ICE'ing on it. -- brooks at gcc dot

[Bug fortran/30285] gfortran excessive memory usage with large modules

2007-04-19 Thread bdavis at gcc dot gnu dot org
--- Comment #11 from bdavis at gcc dot gnu dot org 2007-04-20 03:41 --- i think not. i must have confued myself (rather easy to do!). will dig through the source this weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285