[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-02 07:56 --- The essential point is that "b" is allocatable; "a" can be a parameter or a simple dimension(2,2) array. The kind does also not matter. If one uses only conjg or only transpose there is no error. Also, if one reverts the order, i.e. uses transpose(conjg(a)), the result is correct. program testcase implicit none complex, allocatable :: b(:,:) complex,parameter :: a(1,1) = Reshape([ 2 ],[1,1]) allocate(b(1,1)) b = conjg(transpose(a)) ! print *, a ! print *, b end program -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 4.2.1 4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug java/32967] New: [4.3 regression] gcjavac throws java exceptions on startup
I've installed gcc 4.2.1 and 4.3-svn in parallel, 4.2.1 as normal compiler, 4.3 with --program-suffix=-4.3 (and with contrib/download_ecj). Trying to use gcjavac from 4.3 results in: $ gcjavac-4.3 test.java java.lang.NullPointerException at java.lang.String.(libgcj.so.9) at org.eclipse.jdt.internal.compiler.batch.FileSystem.initializeKnownFileNames(FileSystem.java:192) at org.eclipse.jdt.internal.compiler.batch.FileSystem.(FileSystem.java:128) at org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3271) at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3379) at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1607) at org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(GCCMain.java:474) at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:491) Or, when forcing libgcj into the CLASSPATH: $ CLASSPATH=/usr/share/java/libgcj-4.3.0.jar gcjavac-4.3 test.java java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.ast.MethodDeclaration cannot be cast to org.eclipse.jdt.internal.compiler.ast.AnnotationMethodDeclaration at org.eclipse.jdt.internal.compiler.parser.Parser.consumeMethodHeaderExtendedDims(Parser.java:4223) at org.eclipse.jdt.internal.compiler.parser.Parser.consumeRule(Parser.java:5184) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9007) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9238) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9195) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7851) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:587) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:357) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:371) at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3410) at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1607) at org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(GCCMain.java:474) at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:491) org.eclipse.jdt.internal.compiler.ast.MethodDeclaration cannot be cast to org.eclipse.jdt.internal.compiler.ast.AnnotationMethodDeclaration (test.java is just a simple hello world-style app) -- Summary: [4.3 regression] gcjavac throws java exceptions on startup Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org 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=32967
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #17 from dominiq at lps dot ens dot fr 2007-08-02 08:06 --- The following reduced cas: integer,allocatable :: foo(:,:) allocate(foo(0,1:7)) print *, pack(foo(:,1),foo(:,1)==0,(/1,2/)) deallocate(foo) end gives a "Bus error" when run. It works if I replace the mask by a scalar or if I remove the vector (/1,2/). This is for gfortran 4.3.0 revision 127147 for which I have reloaded iresolve.c from the repository (anyway I had the right version). Do you see the bus error? or is it a bug for big endian machines only? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #18 from dominiq at lps dot ens dot fr 2007-08-02 09:53 --- The test of #17 pass on AMD64 with gfortran 4.3.0 20070713, but fails on PPC Darwin8 with gfortran 4.3.0 20070802. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug target/29493] -masm=intel - does not emit right asm code
--- Comment #2 from rask at sygehus dot dk 2007-08-02 09:42 --- It's still broken as of "4.3.0 20070729 (experimental)". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29493
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #8 from brett dot albertson at stratech dot com 2007-08-02 12:00 --- In my nightly automated testing I got this last night: < FAIL: gcc.dg/pr28796-2.c (test for excess errors) < WARNING: gcc.dg/pr28796-2.c compilation failed to produce executable --- > PASS: gcc.dg/pr28796-2.c (test for excess errors) > PASS: gcc.dg/pr28796-2.c execution test Which is a new failure. I'm assuming this is related to what you checked in earlier. Let me know if you need more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug middle-end/24952] ICE: RTL check: expected code 'set' or 'clobber', have 'unspec' in try_combine, at combine.c:2898
--- Comment #4 from bergner at gcc dot gnu dot org 2007-08-02 13:42 --- Subject: Bug 24952 Author: bergner Date: Thu Aug 2 13:42:06 2007 New Revision: 127160 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127160 Log: Backport from mainline. 2006-02-24 Roger Sayle <[EMAIL PROTECTED]> PR middle-end/24952 * combine.c (try_combine): Explicitly check whether GET_CODE is a SET or a CLOBBER, instead on checking that it isn't a USE. 2006-11-22 Peter Bergner <[EMAIL PROTECTED]> * config/rs6000/rs6000.c (get_store_dest): New. (adjacent_mem_locations): Use get_store_dest() to get the rtl of the store destination. Modified: branches/ibm/gcc-4_1-branch/gcc/ChangeLog branches/ibm/gcc-4_1-branch/gcc/combine.c branches/ibm/gcc-4_1-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24952
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #12 from pluto at agmk dot net 2007-08-02 13:29 --- (In reply to comment #11) > Created an attachment (id=14004) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14004&action=view) [edit] my gcc-4.2.1 (which is almost like FSF release) produces for attached preprocessed file reasonable code that contains interrupt routines. $ gcc -m32 -O2 -march=c3 -fno-strict-aliasing --save-temps -c i8259.i $ nm i8259.o |grep inter 0020 t IRQ0x00_interrupt 0030 t IRQ0x01_interrupt 0040 t IRQ0x02_interrupt 0050 t IRQ0x03_interrupt 0060 t IRQ0x04_interrupt 0070 t IRQ0x05_interrupt 0080 t IRQ0x06_interrupt 0090 t IRQ0x07_interrupt 00a0 t IRQ0x08_interrupt 00b0 t IRQ0x09_interrupt 00c0 t IRQ0x0a_interrupt 00d0 t IRQ0x0b_interrupt 00e0 t IRQ0x0c_interrupt 00f0 t IRQ0x0d_interrupt 0100 t IRQ0x0e_interrupt 0110 t IRQ0x0f_interrupt t common_interrupt D interrupt the 4.2 object from the first attachment hasn't interrupt code located in the .text section. it has only .bss entries and this is a reason of the crash-on-first-interrupt. $ nm i8259.o_gcc42 |grep inter 0030 b IRQ0x00_interrupt 0040 b IRQ0x01_interrupt 0050 b IRQ0x02_interrupt 0060 b IRQ0x03_interrupt 0070 b IRQ0x04_interrupt 0080 b IRQ0x05_interrupt 0090 b IRQ0x06_interrupt 00a0 b IRQ0x07_interrupt 00b0 b IRQ0x08_interrupt 00c0 b IRQ0x09_interrupt 00d0 b IRQ0x0a_interrupt 00e0 b IRQ0x0b_interrupt 00f0 b IRQ0x0c_interrupt 0100 b IRQ0x0d_interrupt 0110 b IRQ0x0e_interrupt 0120 b IRQ0x0f_interrupt 0010 b common_interrupt D interrupt btw, the 4.3 snapshot ICEs on this code ;) Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00a4a85c in cpp_interpret_string (pfile=0xf5bd40, from=, count=1, to=0x7fff77f942f0, wide=0 '\0') at ../../libcpp/charset.c:1334 #2 0x00a4b120 in cpp_interpret_string_notranslate (pfile=0x, from=0xf5f8c3, count=7, to=0x7fff77f94270, wide=3 '\003') at ../../libcpp/charset.c:1369 #3 0x00a4e408 in do_linemarker (pfile=0xf5bd40) at ../../libcpp/directives.c:924 #4 0x00a4d36d in _cpp_handle_directive (pfile=0xf5bd40, indented=0) at ../../libcpp/directives.c:468 #5 0x00a53963 in cpp_read_main_file (pfile=0xf5bd40, fname=) at ../../libcpp/init.c:518 #6 0x004616c1 in c_common_post_options (pfilename=0xf2a090) at ../../gcc/c-opts.c:1190 #7 0x00689f00 in toplev_main (argc=12, argv=0x7fff77f94508) at ../../gcc/toplev.c:1693 #8 0x004851b9 in main (argc=-1, argv=0xf5f8c3) at ../../gcc/main.c:35 -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-08-02 14:14 --- (In reply to comment #8) > In my nightly automated testing I got this last night: > < FAIL: gcc.dg/pr28796-2.c (test for excess errors) > < WARNING: gcc.dg/pr28796-2.c compilation failed to produce executable > --- > > PASS: gcc.dg/pr28796-2.c (test for excess errors) > > PASS: gcc.dg/pr28796-2.c execution test > Which is a new failure. I'm assuming this is related to what you checked in > earlier. Let me know if you need more information. There was a file missing from my last checkin which this testcase now includes. Should be okay now, sorry for the breakage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug target/30961] [4.1/4.2 regression] redundant reg/mem stores/moves
--- Comment #17 from hjl at lucon dot org 2007-08-02 14:20 --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > (In reply to comment #13) > > > > Created an attachment (id=13550) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=view) [edit] > > > > An experimental patch > > > > > > > > This patch works for the testcase. > > > > > > i've applied this patch to 4.2.1 and compile testcases: > > > > > > convert/m32/m64 look fine. load/m32/m64 still look unoptimal. > > > > > > > Gcc 4.3 works: > > naturally but its not even been released yet. > users awaiting regression fixes for released compilers ;) > Load is fixed by dataflow merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug middle-end/25445] -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:40 --- Subject: Bug 25445 Author: froydnj Date: Thu Aug 2 14:40:36 2007 New Revision: 127162 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127162 Log: PR middle-end/25445 * varasm.c (default_binds_local_p_1): Consult flag_whole_program if we are compiling with -fPIC. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25445
[Bug middle-end/25446] -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:43 --- Subject: Bug 25446 Author: froydnj Date: Thu Aug 2 14:42:53 2007 New Revision: 127163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127163 Log: PR middle-end/25446 * c-objc-common.c (c_cannot_inline_tree_fn): Check for an always_inline attribute on the function decl. Modified: trunk/gcc/ChangeLog trunk/gcc/c-objc-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25446
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #13 from axel at freakout dot de 2007-08-02 15:05 --- Subject: Re: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3 According to pluto at agmk dot net: > > my gcc-4.2.1 (which is almost like FSF release) produces for attached > preprocessed file reasonable code that contains interrupt routines. > the compiler is build form the gnu distribution on this machine and has compiled lots of packages without a problem. also 2.4.35 kernels for i386(plain) and P3-optimized work without any problem within the same build environment and this compiler. what should i verify with my gcc-4.2.1 installation? maybe the options for the Linux build system make the difference?: + gcc4 --version gcc4 (GCC) 4.2.1 Copyright (C) 2007 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. + gcc4 -D__KERNEL__ --save-temps -I/src/kernel/linux-2.4.35-ARX/include \ -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing \ -fno-common -fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign \ -pipe -mpreferred-stack-boundary=2 -march=c3 -falign-functions=0 -falign-jumps=0 \ -falign-loops=0 -fno-unit-at-a-time -nostdinc -iwithprefix include \ -DKBUILD_BASENAME=i8259 -c -o i8259.o i8259.c gcc4: warning: -pipe ignored because -save-temps specified + nm i8259.o | grep inter 0030 b IRQ0x00_interrupt 0040 b IRQ0x01_interrupt 0050 b IRQ0x02_interrupt 0060 b IRQ0x03_interrupt 0070 b IRQ0x04_interrupt 0080 b IRQ0x05_interrupt 0090 b IRQ0x06_interrupt 00a0 b IRQ0x07_interrupt 00b0 b IRQ0x08_interrupt 00c0 b IRQ0x09_interrupt 00d0 b IRQ0x0a_interrupt 00e0 b IRQ0x0b_interrupt 00f0 b IRQ0x0c_interrupt 0100 b IRQ0x0d_interrupt 0110 b IRQ0x0e_interrupt 0120 b IRQ0x0f_interrupt 0010 b common_interrupt D interrupt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #6 from widman at gimpel dot com 2007-08-02 15:56 --- (In reply to comment #4) > I should note that I do NOT want to see this bug fixed. I would prefer to hear > that you won't "fix" it at all. So I can exploit this behavior as there is no > standards-compliant way of achieving the same results. Is it possible that rvalue references will give you an alternative for the desired effect? See the relevant papers linked to from here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html -- widman at gimpel dot com changed: What|Removed |Added CC||widman at gimpel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #19 from dominiq at lps dot ens dot fr 2007-08-02 15:49 --- Created an attachment (id=14009) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14009&action=view) gdb session from entering pack_internal to the crash I have also had a look to the results of -fdump-tree-original and to the assembly with and without the flag, but did not see anything obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #23 from dominiq at lps dot ens dot fr 2007-08-02 16:03 --- Revision 127147, plus unconditional #undef isfinite plus patches from A Pinski: http://gcc.gnu.org/ml/gcc-bugs/2007-07/msg02997.html from FX coudert: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02206.html gives after ~7 hours!-(1h 20mn = 16*300s could be saved by fixing gfortran.fortran-torture/execute/equiv_5.f): Test Run By dominiq on Thu Aug 2 09:44:20 2007 Native configuration is powerpc-apple-darwin8 === gfortran tests === Schedule of variations: unix unix/-m64 unix//-fdefault-integer-8 unix/-m64/-fdefault-integer-8 Running target unix FAIL: gfortran.dg/large_real_kind_2.F90 -O0 execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O1 execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O2 execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_2.F90 -Os execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -Os execution test === gfortran Summary for unix === # of expected passes19919 # of unexpected failures16 # of expected failures 9 # of unsupported tests 58 The above failures + FAIL: gfortran.dg/vect/vect-2.f90 -O scan-tree-dump-times Alignment of access forced using peeling 3 XPASS: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times Vectorizing an unaligned access 2 FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Vectorizing an unaligned access 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times Alignment of access forced using peeling 1 === gfortran Summary for unix/-m64 === # of expected passes19947 # of unexpected failures20 # of unexpected successes 1 # of expected failures 8 # of unsupported tests 42 Failures skipped === gfortran Summary for unix//-fdefault-integer-8 === # of expected passes18951 # of unexpected failures692 <-- from 750 # of expected failures 7 # of untested testcases 32 # of unsupported tests 44 Failures skipped === gfortran Summary for unix/-m64/-fdefault-integer-8 === # of expected passes19077 # of unexpected failures609 <-- from 659 # of unexpected successes 1 # of expected failures 6 # of untested testcases 32 # of unsupported tests 28 === gfortran Summary === # of expected passes77894 # of unexpected failures1337 # of unexpected successes 2 # of expected failures 30 # of untested testcases 64 # of unsupported tests 172 /opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070802 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32968] New: selected_(int|real)_kind fail with -fdefault-integer-8
the following code integer i do i = 1, 10 print *, selected_int_kind (i) end do end gives with -fdefault-integer-8 '4294967424' 10 times on PPC Darwin8 and 4294967297 8589934593 12884901890 17179869186 21474836484 25769803780 30064771076 34359738372 38654705668 42949672968 on AMD64 Linux. Likewisethe following integer i do i = 1, 10 print *, selected_real_kind (i) end do end gives '17179869312' 10 times on PPC and 4294967300 8589934596 12884901892 17179869188 21474836484 25769803780 30064771080 34359738376 38654705672 42949672968 on AMD. -- Summary: selected_(int|real)_kind fail with -fdefault-integer-8 Product: gcc Version: 4.3.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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32969] New: (rr)?spacing give wrong answers with -fdefault-integer-8
With -fdefault-integer-8 the following code: program test_rrspacing real x x = 3.0 x = rrspacing(x) print *, x, spacing(x), spacing(3.0) x = 3.0 x = spacing(x) print *, x end gives: 0.750 1.6777216E+07 2.3841858E-07 1.6777216E+07 instead of 1.2582912E+07 1.00 2.3841858E-07 2.3841858E-07 Note that like PR32933 the code does not involve directly integers and as in the original test of PR32770 it seems to be linked to bigendian platforms (PPC here). -- Summary: (rr)?spacing give wrong answers with -fdefault-integer-8 Product: gcc Version: 4.3.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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32969
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-02 16:32 --- For my testcase (with parameter) I find the following in the original dump: (*D.1371)[(S.4 + D.1380) * D.1384 + D.1387] = CONJ_EXPR <(*(complex4[0:] *) parm.1.data)[S.4 * D.1383 + D.1386]>; Rewritten this is: b.data[(0+1)*1+(-1)] = CONJ_EXPR< a.data[0*1+(-2)]> or shorter: b.data[0] = a.data[-2] For A: S.4 * D.1383 + D.1386 = 0 * 1 + (-2) = -2 where S.4 = 0 loop variable D.1383 = 1 (a.dim[0].stride) D.1386 = a.offset + a.dim[1].stride * S.4 = -2 + 1 * 0 and for B: (S.4 + D.1380) * D.1384 + D.1387 = (0 + 1 ) * 1 + (-1) = 0 where S.4 = 0 loop variable D.1380 = b.lbound = 1 D.1384 = b.dim[0].stride = 1 D.1387 = a.offset + a.dim[1].stride * S.3 = (-2) + 1 * 0 S.3 = 0 other loop variable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
mips64vrel-elf code gen bug
Hi Eric, Hi Richard, We have received a bug report against the mips64vrel-elf toolchain which is reproducible with the mainline sources. Since it (appears to) involve MIPS code generation and I know almost nothing about MIPS I am passing it on to you in the hopes that you might be able to fix it, or at least point me in the right direction. To reproduce the problem compile the attached two files with: % mips64vrel-elf 128201-1.c 128201-2.c -Tddb.ld -mabi=32 -march=vr5000 Then run it with the simulator: % mips64vrel-elf-run a.out FPR 4 (format single) being accessed with format double - setting to unknown (PC = 0xa0100364) -2.33 (-2.33) Note the error message from the simulator. The problem appears to be $f4 register used by the sub.d instruction. I suspect, but do not know for sure, that this is somehow connected with the store_df_high pattern in mips.md. Any clues or solutions ? Cheers Nick 128201-files.tar.bz2 Description: BZip2 compressed data
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #7 from aribrei at arcor dot de 2007-08-02 16:34 --- (In reply to comment #6) > (In reply to comment #4) > > I should note that I do NOT want to see this bug fixed. I would prefer to > > hear > > that you won't "fix" it at all. So I can exploit this behavior as there is > > no > > standards-compliant way of achieving the same results. > > Is it possible that rvalue references will give you an alternative for the > desired effect? See the relevant papers linked to from here: > > http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html > This would mean that instead of A::A(A &), I wrote A::A(A &&) and passing temporaries would automatically work? (Not sure if I correctly understand the r-value reference proposal.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-02 16:37 --- Subject: Re: Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8 > These two examples are the poster child for > 1) Why -fdefault-integer-8 is a bad option and should only be >used by people who are prepared to have broken results. > 2) Why EQUIVALENCE is a horribly abused construct. This reminds me a very old joke I have read about a famous computer company: ... is like death or taxes, you don't like them, but you cannot escape them! More seriously I find the -fdefault-integer-8 option of rather dubious interest, at least as a physicist. However -fdefault-real-8 is one of the feature my colleagues keep asking for. It is very handy to test the benefits of doubles in term of accuracy and their drawbacks in term of CPU and memory. Indeed if you find a critical application relying on these options, you are right to be worried. > In fact, from equiv_7.f90, this is invalid Yes, g95 emits a lot of warnings about nonstandard equivalences in that case and gfortran detects the problem. However this construct is the only way I know in f77 to access memory in different ways (as done in the two cases to cope with endnian madness) so you are likely to find it in many old libraries. What is more interesting is why the problem is not detected in the second case and why the executable hangs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug c/31886] (different from bug report c/31077 and 29241) C handling of always_inline attribute error and a solution
--- Comment #7 from rob1weld at aol dot com 2007-08-02 17:24 --- Created an attachment (id=14010) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14010&action=view) Example of kernel file that causes "inlining failed" error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #20 from tkoenig at gcc dot gnu dot org 2007-08-02 17:17 --- (In reply to comment #19) > I have also had a look to the results of -fdump-tree-original and to the > assembly with and without the flag, but did not see anything obvious. This is very strange. sptr gets clobbered somewhere. Within gdb, can you set a watchpoint on sptr and rerun the session? That should allow you to catch where the change is made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #8 from widman at gimpel dot com 2007-08-02 17:07 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Is it possible that rvalue references will give you an alternative for the
> > desired effect? See the relevant papers linked to from here:
> >
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html
> >
>
> This would mean that instead of A::A(A &), I wrote A::A(A &&) and passing
> temporaries would automatically work?
That's correct. Rvalues would bind directly to the 'A&&' parameter; you could
even have two ctors:
struct A {
A(const A&); // copy ctor
A(A&&); // move ctor
};
...and when you initialize an 'A' with an rvalue, overload resolution will
select the move ctor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 17:08 --- Subject: Re: C/Fortran interoperability and -fdefault-integer-8 > A check of this option can be inserted at various locations during > the parsing. Certainly, but this will give a very interesting exercise to build test cases! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #9 from widman at gimpel dot com 2007-08-02 17:17 --- See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939 So it seems you should be able to play with it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug c/31886] (different from bug report c/31077 and 29241) C handling of always_inline attribute error and a solution
--- Comment #6 from rob1weld at aol dot com 2007-08-02 17:18 ---
I can confirm this too. Here is the bug report I was to post - but I searched
to see if this was already reported ;) - Here are my notes:
tree-inline.c - sorry, unimplemented: inlining failed ... function body not
available
When compiling the kernel with GCC version 4.3.0 20070630 or 20070716 it seems
to remove (optimize away) functions which are needed. When GCC later discovers
it needs the function afterall it crys "function body not available" and
terminates the build with an error.
This does not occur if I add "-O0" on the end of the command line. :(
I also do not have this problem when using GCC version 4.2.1 20070628 .
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.22-rc2.tar.bz2
make V=1 vmlinux
...
/usr/test/bin/gcc -Wp,-MD,kernel/.futex.o.d -nostdinc -isystem
/usr/test/lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude
-Iinclude2 -Ilinux-2.6.22-rc2-source/include -include include/linux/autoconf.h
-Ilinux-2.6.22-rc2-source/kernel -Ikernel -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -fprofile-arcs
-ftest-coverage -D__arch_um__ -DSUBARCH=\"i386\"
-Ilinux-2.6.22-rc2-source/arch/um/include -Iarch/um/include
-Ilinux-2.6.22-rc2-source/arch/um/include
-Ilinux-2.6.22-rc2-source/arch/um/include/skas -Dvmap=kernel_vmap
-Din6addr_loopback=kernel_in6addr_loopback -march=k8
-mpreferred-stack-boundary=2 -ffreestanding -D_LARGEFILE64_SOURCE
-Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask -Dmktime=kernel_mktime
-U__i386__ -Ui386 -fno-unit-at-a-time -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -fno-stack-protector
-Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(futex)"
-D"KBUILD_MODNAME=KBUILD_STR(futex)" -c -o kernel/.tmp_futex.o
linux-2.6.22-rc2-source/kernel/futex.c
linux-2.6.22-rc2-source/kernel/futex.c: In function 'futex_requeue_pi':
linux-2.6.22-rc2-source/kernel/futex.c:272: sorry, unimplemented: inlining
failed in call to 'get_futex_key_refs': function body not available
linux-2.6.22-rc2-source/kernel/futex.c:908: sorry, unimplemented: called from
here
make[2]: *** [kernel/futex.o] Error 1
make[1]: *** [kernel] Error 2
make: *** [vmlinux] Error 2
make: Leaving directory `linux-2.6.22-rc2-source'
The message comes from this file: gcc-4_3-trunk/gcc/tree-inline.c , line 2443:
sorry ("inlining failed in call to %q+F: %s", fn, reason);
sorry ("called from here");
and from here, /opt/gcc-4_3-trunk/gcc/diagnostic.def :
DEFINE_DIAGNOSTIC_KIND (DK_SORRY, "sorry, unimplemented: ")
The same problem occurs when compiling these files:
linux-2.6.22-rc2-source/mm/filemap.c
linux-2.6.22-rc2-source/fs/buffer.c
linux-2.6.22-rc2-source/fs/bio.c
linux-2.6.22-rc2-source/fs/block_dev.c
linux-2.6.22-rc2-source/fs/reiserfs/do_balan.c
linux-2.6.22-rc2-source/fs/reiserfs/namei.c
linux-2.6.22-rc2-source/fs/reiserfs/stree.c
linux-2.6.22-rc2-source/block/elevator.c
linux-2.6.22-rc2-source/block/ll_rw_blk.c
linux-2.6.22-rc2-source/net/ipv4/ip_output.c
linux-2.6.22-rc2-source/net/ipv4/igmp.c and
linux-2.6.22-rc2-source/include/net/dst.h
linux-2.6.22-rc2-source/net/ipv4/xfrm4_output.c and
linux-2.6.22-rc2-source/include/net/dst.h
linux-2.6.22-rc2-source/fs/udf/partition.c
linux-2.6.22-rc2-source/net/ipv4/ipvs/ip_vs_xmit.c
linux-2.6.22-rc2-source/net/ipv4/netfilter/nf_nat_rule.c
linux-2.6.22-rc2-source/net/ipv6/ip6_output.c
linux-2.6.22-rc2-source/net/ipv6/ip6_input.c
linux-2.6.22-rc2-source/net/ipv6/ndisc.c
linux-2.6.22-rc2-source/net/ipv6/mcast.c
I tried this line in the kernel Makefile but still got the same error message:
CFLAGS_futex.o += $(call cc-ifversion, -ge, 0403, -fno-inline)
I would have preferred if that had worked rather than resorting to "-O0" since
there are so many files affected by this issue.
I worked around this problem by editing
"linux-2.6.22-rc2-source/kernel/Makefile" (and all the other makefiles) by
adding this sort of line near the top of the Makefile:
CFLAGS_futex.o += $(call cc-ifversion, -ge, 0403, -O0)
That allows the kernel to build with GCC 4.3 but does not "fix" GCC itself.
Here is the minimum command line to trigger the problem:
gcc -O1 -fno-unit-at-a-time -c -o futex.o futex.i
linux-2.6.22-rc2-source/kernel/futex.c: In function 'futex_requeue_pi':
linux-2.6.22-rc2-source/kernel/futex.c:272: sorry, unimplemented: inlining
failed in call to 'get_futex_key_refs': function body not available
linux-2.6.22-rc2-source/kernel/futex.c:908: sorry, unimplemented: called from
here
If I use "-O0" or leave off "-fno-unit-at-a-time" I don't get the error. These
options are what are present in the kernel's makefile (not my preferences). The
kernel's makefiles are written in a particular way to allow various other
features
to work (so a full overhaul of the all makefiles is out (for me)). If this is
not a problem with GCC 4.3 but instead an issue with the wa
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #21 from dominiq at lps dot ens dot fr 2007-08-02 17:42 --- Created an attachment (id=14011) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14011&action=view) new gdb session with 'watch sptr' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug c++/30850] [4.1/4.2/4.3 regression] ICE with invalid asm statement
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:51 --- Subject: Bug 30850 Author: lmillward Date: Thu Aug 2 17:50:55 2007 New Revision: 127167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167 Log: PR c++/30849 PR c++/30850 PR c++/30851 * parser.c (cp_parser_asm_definition): Detect and discard asm statements with invalid inputs or outputs. (cp_parser_asm_operand_list): Return error mark node if any of the operands are invalid. Adjust documentation. PR c++/30849 * g++.dg/parse/asm1.C: New test. PR c++/30850 * g++.dg/parse/asm2.C: Likewise. PR c++/30851 * g++.dg/parse/asm3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/asm1.C trunk/gcc/testsuite/g++.dg/parse/asm2.C trunk/gcc/testsuite/g++.dg/parse/asm3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30850
[Bug c++/30849] [4.1/4.2/4.3 regression] ICE with invalid asm statement
--- Comment #1 from lmillward at gcc dot gnu dot org 2007-08-02 17:51 --- Subject: Bug 30849 Author: lmillward Date: Thu Aug 2 17:50:55 2007 New Revision: 127167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167 Log: PR c++/30849 PR c++/30850 PR c++/30851 * parser.c (cp_parser_asm_definition): Detect and discard asm statements with invalid inputs or outputs. (cp_parser_asm_operand_list): Return error mark node if any of the operands are invalid. Adjust documentation. PR c++/30849 * g++.dg/parse/asm1.C: New test. PR c++/30850 * g++.dg/parse/asm2.C: Likewise. PR c++/30851 * g++.dg/parse/asm3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/asm1.C trunk/gcc/testsuite/g++.dg/parse/asm2.C trunk/gcc/testsuite/g++.dg/parse/asm3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30849
[Bug c++/30851] [4.1/4.2/4.3 regression] ICE with invalid asm statement
--- Comment #1 from lmillward at gcc dot gnu dot org 2007-08-02 17:51 --- Subject: Bug 30851 Author: lmillward Date: Thu Aug 2 17:50:55 2007 New Revision: 127167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167 Log: PR c++/30849 PR c++/30850 PR c++/30851 * parser.c (cp_parser_asm_definition): Detect and discard asm statements with invalid inputs or outputs. (cp_parser_asm_operand_list): Return error mark node if any of the operands are invalid. Adjust documentation. PR c++/30849 * g++.dg/parse/asm1.C: New test. PR c++/30850 * g++.dg/parse/asm2.C: Likewise. PR c++/30851 * g++.dg/parse/asm3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/asm1.C trunk/gcc/testsuite/g++.dg/parse/asm2.C trunk/gcc/testsuite/g++.dg/parse/asm3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30851
[Bug c++/30851] [4.1/4.2 regression] ICE with invalid asm statement
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:53 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-02 17:53:48 date|| Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with invalid asm statement |with invalid asm statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30851
[Bug c++/30850] [4.1/4.2 regression] ICE with invalid asm statement
--- Comment #3 from lmillward at gcc dot gnu dot org 2007-08-02 17:53 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with invalid asm statement |with invalid asm statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30850
[Bug c++/30849] [4.1/4.2 regression] ICE with invalid asm statement
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:52 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with invalid asm statement |with invalid asm statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30849
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-02 17:51 --- I have a patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-02 17:51:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug c++/32970] New: C++ frontend can not handle vector pointer constant parameter
When compiling a function with parameter of a pointer to a vector constant
type, the compiler calls a recursive function and is not able to get out.
Concretely, in gcc/cp/mangle.c file, in function write_type:
if (write_CV_qualifiers_for_type (type) > 0)
/* If TYPE was CV-qualified, we just wrote the qualifiers; now
mangle the unqualified type. The recursive call is needed here
since both the qualified and unqualified types are substitution
candidates. */
write_type (TYPE_MAIN_VARIANT (type));
But TYPE_MAIN_VARIANT (type) has been set as type itself in gcc/tree.c
function make_node_stat:
case tcc_type:
...
TYPE_MAIN_VARIANT (t) = t;
Therefor the write_type function runs into a dead recursion.
The bug was detected on spu, and the same error appears on PowerPC and Intel
too.
The following is a test case on Intel:
void bar(
int __attribute__((vector_size(16))) * a,
int __attribute__((vector_size(16))) * const b);
int instance(void)
{
int __attribute__((vector_size(16))) a[1], b[1];
bar(a, b);
}
--
Summary: C++ frontend can not handle vector pointer constant
parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saliu at de dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: spu-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #10 from aribrei at arcor dot de 2007-08-02 18:39 --- (In reply to comment #9) > See also: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939 > > So it seems you should be able to play with it now. > Unfortunately, I have to support older GCC version (like 4.0 and 4.1) for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug target/32431] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4066
--- Comment #3 from zadeck at naturalbridge dot com 2007-08-02 19:19 --- Given that the rtl passes are moving to not allow illegally shared rtl, i do not believe that the resolution of this bug has anything to do with the dataflow port. If this bug is to be resolved, it will be done by cleaning up this back end. -- zadeck at naturalbridge dot com changed: What|Removed |Added CC|zadeck at naturalbridge dot | |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #14 from pluto at agmk dot net 2007-08-02 19:42 ---
yup, i see something new :)
please look at line 12137 of i8259.i:
__attribute__((regparm(0))) void call_do_IRQ(void); __asm__(...
as you can see there is a semicolon after call_do_IRQ(void)
and following asm statement isn't treated as a function body.
in this way -O1 -f{no-}unit-at-a-time accidentally produces
different code. it's not a gcc bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #15 from axel at freakout dot de 2007-08-02 19:55 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
>
> as you can see there is a semicolon after call_do_IRQ(void)
> and following asm statement isn't treated as a function body.
> in this way -O1 -f{no-}unit-at-a-time accidentally produces
> different code. it's not a gcc bug.
>
but who's bug is it?
what component in my tool-chain is to blame for that?
please give me a tip.
Axel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #24 from tkoenig at gcc dot gnu dot org 2007-08-02 20:08 --- Subject: Bug 32770 Author: tkoenig Date: Thu Aug 2 20:07:54 2007 New Revision: 127168 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127168 Log: 2007-08-02 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32770 * gfortran.dg/unf_read_corrupted_1.f90: Make all kinds explicit so test passes with -fdefault-integer-8. * gfortran.dg/unformatted_recl_1.f90: Likewise. * gfortran.dg/unformatted_subrecord_1.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unf_read_corrupted_1.f90 trunk/gcc/testsuite/gfortran.dg/unformatted_recl_1.f90 trunk/gcc/testsuite/gfortran.dg/unformatted_subrecord_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #25 from tkoenig at gcc dot gnu dot org 2007-08-02 20:19 --- One additional thought. When we add -fdefault-integer-8 to the testsuite (finally :-) we should also add -fdeault-real-8 as well so the sizes of integers and reals match in common blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 20:26 --- If we use -fdefault-integer-8 on code which includes common or equivalences, we should also include -fdefault-real-8. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 20:32 --- Subject: Re: Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8 On Thu, Aug 02, 2007 at 08:26:44PM -, tkoenig at gcc dot gnu dot org wrote: > > If we use -fdefault-integer-8 on code which includes common > or equivalences, we should also include -fdefault-real-8. > It doesn't help in this case. The equivalence statement is a double precision variable and a 2 element integer array. It's the old trick of using the array to access the hi and lo word of the double precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 20:38 --- Same place to ICE for bounds_check_5.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 20:55 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 Steve, I applied your patch, but on PPC Darwin I get 10 times 1 for int, instead of: 1 1 2 2 4 4 4 4 4 8 and 10 times 4 for real, instead of 4 4 4 4 4 4 8 8 8 8 Is it yet another endian problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-02 20:56 --- CONJ_EXPR< a.data[0*1+(-2)]> The offset = -2 is generated in gfc_conv_expr_descriptor: offset = gfc_index_zero_node; for (n = 0; n < ndim; n++) // ndim = 2 start = info->start[dim]; // start = 0; tmp = gfc_conv_array_lbound (desc, n); // "tmp = 1" // "tmp = 0 - 1 = -1" tmp = fold_build2 (MINUS_EXPR, TREE_TYPE (tmp), start, tmp); // tmp = tmp * 1 = -1 tmp = fold_build2 (MULT_EXPR, TREE_TYPE (tmp), tmp, stride); // offset = offset + tmp = offset + (-1) offset = fold_build2 (PLUS_EXPR, TREE_TYPE (tmp), offset, tmp); Still, I don't quite understand how it is supposed to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:06 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 10:55:45PM +0200, Dominique Dhumieres wrote:
>
> I applied your patch, but on PPC Darwin I get 10 times 1 for int, instead of:
>
> 1 1 2 2 4 4 4 4 4 8
>
What is the -fdump-tree-original for
i = 4
print *, selected_int_kind(i)
print *, selected_real_kind(i)
end
without -fdefault-integer-8 I get
{
int4 D.996;
D.996 = _gfortran_selected_int_kind (&i);
_gfortran_transfer_integer (&dt_parm.1, &D.996, 4);
}
{
int4 D.998;
D.998 = _gfortran_selected_real_kind (&i, 0B);
_gfortran_transfer_integer (&dt_parm.2, &D.998, 4);
}
with it I get
{
int8 D.996;
D.996 = (int8) _gfortran_selected_int_kind (&i);
_gfortran_transfer_integer (&dt_parm.1, &D.996, 8);
}
{
int8 D.998;
D.998 = (int8) _gfortran_selected_real_kind (&i, 0B);
_gfortran_transfer_integer (&dt_parm.2, &D.998, 8);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-02 21:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> What is the -fdump-tree-original for
without:
{
int4 D.966;
D.966 = _gfortran_selected_int_kind (&i);
_gfortran_transfer_integer (&dt_parm.1, &D.966, 4);
}
{
int4 D.968;
D.968 = _gfortran_selected_real_kind (&i, 0B);
_gfortran_transfer_integer (&dt_parm.2, &D.968, 4);
}
with:
{
int8 D.966;
D.966 = (int8) _gfortran_selected_int_kind (&i);
_gfortran_transfer_integer (&dt_parm.1, &D.966, 8);
}
{
int8 D.968;
D.968 = (int8) _gfortran_selected_real_kind (&i, 0B);
_gfortran_transfer_integer (&dt_parm.2, &D.968, 8);
}
look to yours, but with -fdefault-integer-8, I get '1 4' instead of
'2 4'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:42 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote:
>
> look to yours, but with -fdefault-integer-8, I get '1 4' instead of
> '2 4'.
We probably wanted to use 'i = 10', which should gives '8 8'.
In looking at the dump again (removing the stuff from PRINT), we have
int8 i;
i = 10;
{
{
int8 D.996;
D.996 = (int8) _gfortran_selected_int_kind (&i);
_gfortran_transfer_integer (&dt_parm.1, &D.996, 8);
}
I bet I need to force 'i' to int4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug testsuite/19232] Failure in gcc.dg/assign-warn-3.c on i686-pc-linux-gnu with -fpic/-fPIC
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-02 21:59 --- Nathan Froyd checked in a patch for this. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19232
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 22:29 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote: > > look to yours, but with -fdefault-integer-8, I get '1 4' instead of > '2 4'. Dominique, Can you try the attached patch? --- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 22:29 --- Created an attachment (id=14012) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14012&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug libgcj/32967] [4.3 regression] gcjavac throws java exceptions on startup
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 23:01 --- Are you sure that this is not a bug in the ecj version that is on the ftp site? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32967
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #8 from dominiq at lps dot ens dot fr 2007-08-02 23:02 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 > Can you try the attached patch? It fixes the problem for -fdefault-integer-8, but without it, it gives on your test (and others) the infamous: intrinsic_sir_kind_red.f90:4.3: end 1 Internal Error at (1): intrinsic_sir_kind_red.f90:3.28: print *, selected_real_kind(i) 1 Can't convert INTEGER(4) to INTEGER(4) at (1) I think you need the same kind of machinery as for PR32954, i.e., change to 4 only if it is different from 4. BTW, did you consider the second optional argument for selected_real_kind(i)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 23:49 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote: > > > --- Comment #8 from dominiq at lps dot ens dot fr 2007-08-02 23:02 > --- > Subject: Re: selected_(int|real)_kind fail with > -fdefault-integer-8 > > > Can you try the attached patch? > > It fixes the problem for -fdefault-integer-8, but without it, > it gives on your test (and others) the infamous: > > intrinsic_sir_kind_red.f90:4.3: > > end > 1 > Internal Error at (1): > intrinsic_sir_kind_red.f90:3.28: > > print *, selected_real_kind(i) >1 > Can't convert INTEGER(4) to INTEGER(4) at (1) > > I think you need the same kind of machinery as for > PR32954, i.e., change to 4 only if it is different from 4. That's next. :-) > BTW, did you consider the second optional argument for > selected_real_kind(i)? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2007-08-03 00:04 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote: > > I think you need the same kind of machinery as for > PR32954, i.e., change to 4 only if it is different from 4. > BTW, did you consider the second optional argument for > selected_real_kind(i)? > I think that we may be converging on a patch. Can you test the attached diff? --- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2007-08-03 00:04 --- Created an attachment (id=14013) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14013&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #12 from dominiq at lps dot ens dot fr 2007-08-03 00:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> I think that we may be converging on a patch. Can you test
> the attached diff?
I have converged in the same direction (modulo the coding style!-):
+ if (actual->expr->ts.kind != 4)
+ {
+ts.type = BT_INTEGER;
+ts.kind = 4;
+gfc_convert_type (actual->expr, &ts, 2);
+ }
It pass my tests and it will regtest while I am going to bed (2AM my time).
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32969] (rr)?spacing give wrong answers with -fdefault-integer-8
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-03 04:46 --- I Know how to fix the problems with spacing and rrspacing. Patch is forthcoming. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-03 04:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32969
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #8 from kargl at gcc dot gnu dot org 2007-08-03 04:29 --- Change severity to "normal". Yes, I know the bug is "critical" to Wirawan, but a Fortran bug is rarely considered "critical". -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug inline-asm/32971] New: Inline asm with offset addressing fails to compile in 4.0+ without -O
The following test case fails to compile without optimization with gcc 4.3.0
(20070503 (experimental)), 4.1.2 (20070502 (Red Hat 4.1.2-12)), and 4.0.4
(20060904 (prerelease) (Debian 4.0.3-7)), but succeeds with 3.3.6 (Debian
1:3.3.6-15) and 3.4.6 (Debian 3.4.6-5). With optimization (-O and -O2), it
compiles fine with all of the gcc versions mentioned above.
The failing configurations are generating invalid assembly and gas emits the
following error:
/tmp/ccnbmIy1.s:12: Error: register value used as expression
Looking at the assembly emitted by gcc, the failing case looks like:
lea (%edx)(%eax), %eax
..and with the working configurations, I get the expected code:
lea 4(%eax), %eax
#include
struct coord { int x; int y; };
int *
foo(struct coord * c)
{
int * i;
asm ("lea %1(%2), %0"
: "=r" (i)
: "m" (*(size_t *) offsetof(struct coord, y)),
"r" (c)
: "memory");
return i;
}
--
Summary: Inline asm with offset addressing fails to compile in
4.0+ without -O
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kinetik at orcon dot net dot nz
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32971
[Bug inline-asm/32971] Inline asm with offset addressing fails to compile in 4.0+ without -O
--- Comment #1 from kinetik at orcon dot net dot nz 2007-08-03 04:48 --- Created an attachment (id=14014) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14014&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32971
[Bug inline-asm/32971] Inline asm with offset addressing fails to compile in 4.0+ without -O
--- Comment #2 from kinetik at orcon dot net dot nz 2007-08-03 04:51
---
Using a memory operand to pass the offset value is not ideal in the first
place, but I'm not sure how else I can do it. It looks like the "i" contraint
(immediate value) is what I want, but the following code:
asm ("lea %1(%2), %0"
: "=r" (i)
: "i" (offsetof(struct coord, y)),
"r" (c)
: "memory");
...generates the following assembly, which gas fails to assemble due to syntax
errors:
lea $4(%eax), %eax
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32971
[Bug inline-asm/32971] Inline asm with offset addressing fails to compile in 4.0+ without -O
--- Comment #3 from kinetik at flim dot org 2007-08-03 05:11 ---
(In reply to comment #2)
> asm ("lea %1(%2), %0"
>: "=r" (i)
>: "i" (offsetof(struct coord, y)),
> "r" (c)
>: "memory");
Bug #29357 suggests that I need to use %c1 rather than %1 here, and indeed this
works and I believe this is the correct solution.
I'm don't know enough to know if the original reason I opened the bug is still
valid (i.e. it's a regression), or if I'm just being bitten by behaviour
changes when I'm abusing the meaning of the operand (I suspect the latter), so
I'll leave the bug open for someone to review and confirm or close.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32971
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #26 from tkoenig at gcc dot gnu dot org 2007-08-03 05:53 --- Subject: Bug 32770 Author: tkoenig Date: Fri Aug 3 05:52:52 2007 New Revision: 127178 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127178 Log: 2007-08-03 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32770 * gfortran.dg/unf_read_corrupted_1.f90: Integer variable in iostat must be default kind. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unf_read_corrupted_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32972] New: performance of pack/unpack
Right now, pack/unpack a) use memcpy, even if a native type is available b) convert mask arguments of kind 1 and 2 to default logical kind, which wastes cycles and memory Case b) is actually true of all intrinsic functions with mask. -- Summary: performance of pack/unpack Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement 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=32972
