Re: How to make use of instruction scheduling to improve performance?
2007/7/29, 吴曦 [EMAIL PROTECTED]: 28 Jul 2007 12:16:51 -0700, Ian Lance Taylor [EMAIL PROTECTED]: 吴曦 [EMAIL PROTECTED] writes: 28 Jul 2007 09:04:01 -0700, Ian Lance Taylor [EMAIL PROTECTED]: 吴曦 [EMAIL PROTECTED] writes: there are some questions after I read the source code today. 1st. if I add the instrumentation before 2nd scheduling; will gcc emit an insn which will be output as a ld instruction later? If this could happen, some ld instruction may not be instrumented... No, gcc won't introduce any new memory load or store instructions after the prologue and epilogue instructions are threaded. It may ~~~ when are prologue and epilogue instructions threaded? (after register allocation? besides, what is the exact meaning of prologue and epilogue instructions are threaded? Would you mind explaining in more detail? thx :-)) If you look in gcc/passes.c you will see the list of passes. The prologue and epilogue instructions are threaded in pass_thread_prologue_and_epilogue. This happens after register ~ Sorry, I didn't find that pass in gcc 4.1.1. This pass is added in the newest gcc? thx. allocation. It means that the prologue and epilogue instructions are ~~ As you have indicated, this pass happens after register allocation, I want to allocate register rather than dedicating register to do the instrumentation calculation, are there any hints to do this? added to the RTL, so that the second scheduling pass can see them. still move them around or eliminate them, though. ~~ emmm, I need to move/remove my instrumentation if necessary... Yes. This is true by definition, since you want to instrument before the second scheduling pass. The scheduler can and will move load and store instructions. You need to set up the dependencies so that your instrumentation will still occur at the right time. 2nd. to identify ld/st instruction (memory access op), I want to modify gen_rtx_SET, the method is that, if I find SRC or DST is an memory operand in gen_rtx_SET, then add instrumentation code before and after the insn to emit. Will this method work? Besides, if some false positives occur, how to correct them (I don't have some very clear idea.) Modifying gen_rtx_SET is probably not the right way to go. That is ~ Then, what about modifying machine description file? Add define_expand for the define_insn which will output ld/st instruction (this define_expand can insert instrumentation insns. Of course, I need to identify the operands to the define_expand contains a memory operand and a reg operand.) That will work in some sense, but if a load or store instruction is eliminated you are quite likely to still have the instrumentation instructions lying around. Ian Thanks for your hints. rest_of_handle_flow2 calls thread_prologue_and_epilogue_insns, maybe I need to move to a newer version of gcc
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
That isn't what I see here. The output binary was definately for a v8plus processor. That would be a UltraSparc 1 at the least. There is no real V8+ architecture, V8+ is an augmented 32-bit ABI for the V9 architecture, the native ABI of the V9 architecture being the 64-bit ABI. The mapping between -mcpu settings and 32-bit ABI levels is as follows: -mcpu 32-bit ABI v7 v7 v8 v8 v9 v8plus ultrasparc v8plusa ultrasparc3v8plusb -- Eric Botcazou
Re: Refactoring tool
Having spent some time looking at the code for gcc it seems reasonably easy(with some suggestions) to traverse the tree generated and write the relevant information to a file. Any suggestions or pointers to related work would be much appreciated. For C and C++, it might be easier to use a stand alone parser. Depending on what you want, these might be sufficient: http://llvm.org/cfe/ http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/ Patrick Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: How to make use of instruction scheduling to improve performance?
吴曦 [EMAIL PROTECTED] writes: Sorry, I didn't find that pass in gcc 4.1.1. This pass is added in the newest gcc? I see from your later message that you found it. allocation. It means that the prologue and epilogue instructions are ~~ As you have indicated, this pass happens after register allocation, I want to allocate register rather than dedicating register to do the instrumentation calculation, are there any hints to do this? added to the RTL, so that the second scheduling pass can see them. The prologue and epilogue will include load and store instructions. If you want to instrument them, then you need to run after prologue and epilogue generation. Perhaps you don't need to instrument those particular loads and stores, or perhaps you can run your instrumentation pass twice. Ian
RE: CSE removing a load that is necessary
On 27 July 2007 18:24, Ian Lance Taylor wrote: Pranav Bhandarkar writes: I am working on a private port and am seeing the following problem. For a function returning a double the value is stored by the function in memory. cse removes one of the two loads (to retrieve this returned value) after the function is called. cse modifies insn 48 as (insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ]) (reg:SI 178 [+4 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID (const_int 2 [0x2]) (expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ])) (nil (nil and also replaces every subsequent use of (reg:SI 180 [+4 ]) with (reg:SI 178 [+4 ]) thus making the above load dead, which gets subsequently removed. This way the result of the function call is lost. My take is that insn 48 should have a REG_RETVAL note ( Infact it does have this but the note is removed by lower_subreg) and cse should be careful when REG_RETVAL and REG_EQUAL appear in the same insn. Is this the right way of going about it ? Am I reading your code correctly when it appears that the __floatunsidf function returns a value in memory rather than via a register? If lower-subreg split up the load from memory, then it was correct to remove the REG_RETVAL note. There may be a bug here in that it should also remove the REG_EQUAL note in that case. It may be that remove_retval_note needs to look for and remove a REG_EQUAL note. Or perhaps this could be another manifestation of the cse gets confused by reg_equal notes on subparts of dimode pseudos if no movdi pattern is defined in the backend bug[*]? Pranav, is there a movdi pattern in your backend? There needs to be one, gcc does get it wrong if you rely on it to break everything down to si-sized movs. cheers, DaveK -- Can't think of a witty .sigline today
Re: Creating gcc-newbies mailing list
On Fri, 2007-07-27 at 05:30 -0400, Robert Dewar wrote: People asking *language* questions are often told to go elsewhere, and that's reasonable. Actually my complaint there would be that too often, people on this list answer such off topic questions (which is fine), and copy the answers to the list (which is not so fine, since it causes more off-topic posts). The only reason I have cc'ed the list on such replies in the past is so that other list members know that the question has been answered in some shape or form and to avoid redundant work in generating replies. I've not seen short two message threads to be a big problem, but I suppose we could adopt the practice of replying in private (but then we might have five people doing that). Ben
Should gcc/DEV-PHASE in gcc 4.2 branch be updated?
Hi Mark, According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19. Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease? H.J.
How to activate instruction scheduling in GCC?
Hi ALL I'm a pure beginner in GCC, and currently working on a project to implement instruction scheduling for a new DSP processor. This processor doesn't have pipeline interlock, so the compiler HAVE to schedule the instruction without relying on hardware help anymore The problem is, I'm a very beginner in GCC. I think the scheduling in GCC is activated by INSN_SCHEDULING variable (in automatically generated file: insn-attr.h), but I don't even know how to activate this variable. Any help would be appreciated -- View this message in context: http://www.nabble.com/How-to-activate-instruction-scheduling-in-GCC--tf4167590.html#a11857079 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: How to activate instruction scheduling in GCC?
petruk_gile [EMAIL PROTECTED] writes: I'm a pure beginner in GCC, and currently working on a project to implement instruction scheduling for a new DSP processor. This processor doesn't have pipeline interlock, so the compiler HAVE to schedule the instruction without relying on hardware help anymore The problem is, I'm a very beginner in GCC. I think the scheduling in GCC is activated by INSN_SCHEDULING variable (in automatically generated file: insn-attr.h), but I don't even know how to activate this variable. INSN_SCHEDULING will automatically be turned on if you have any define_insn_reservation clauses in your CPU.md file. See the Processor pipeline description documentation in the gcc internals manual. That said, the gcc scheduler unfortunately does not work very well for processors which do not have hardware interlocks. The scheduler will lay out the instructions more or less optimally. But the scheduler has no ability to insert nops when they are required to satisfy interlock constraints. I know of two workable approachs. You can either insert the required nops in the TARGET_MACHINE_DEPENDENT_REORG pass or in the TARGET_ASM_FUNCTION_PROLOGUE hook. I personally prefer the latter approach, as it takes effect after all other instruction rearrangement is complete, but there are existing backends which use the former. For an example of inserting nops in TARGET_MACHINE_DEPENDENT_REORG, see the MIPS backend, specifically mips_avoid_hazards. For an example of inserting nops in TARGET_ASM_FUNCTION_PROLOGUE, see the FRV backend, specifically frv_pack_insns. Ian
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-07-29 06:33 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver at kam dot mff dot cuni dot cz writes: rakdver Probably the problem is that -maltivec does not rakdver imply -mabi=altivec, or some similar omission. -maltivec does not imply -mabi=altivec, which is intended. The Bugzilla PR says the target is powerpc64-linux, which implicitly should enable -mabi=altivec. If this is some other target, then the BOOT_CFLAGS should include -mabi=altivec. it's on ppc-linux. Nevertheless, it is suspicious that we allow a fairly natural combination of flags (-O2 -maltivec -ftree-vectorize) to cause misscompilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-07-29 07:16 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver Probably the problem is that -maltivec does not rakdver imply -mabi=altivec, or some similar omission. -maltivec does not imply -mabi=altivec, which is intended. The Bugzilla PR says the target is powerpc64-linux, which implicitly should enable -mabi=altivec. If this is some other target, then the BOOT_CFLAGS should include -mabi=altivec. it's on ppc-linux. I mean, I did the testing on ppc-linux; it is possible that there is another misscompilation on ppc64-linux, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-29 08:10 --- (In reply to comment #5) I have had a quick look and the cause of failures are quite different. Could you please attach the files /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/gfortran.sum and /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/gfortran.log to this PR (possibly compressed, if they're too large)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #5 from dominiq at lps dot ens dot fr 2007-07-29 08:01 --- If you were expecting to be kept buzzy, you'll be glad! The summary is: === gfortran Summary for unix/-fdefault-integer-8//-m32 === # of expected passes18575 # of unexpected failures750 # of expected failures 7 # of untested testcases 39 # of unsupported tests 44 === gfortran Summary for unix/-fdefault-integer-8//-m64 === # of expected passes18708 # of unexpected failures659 # of unexpected successes 1 # of expected failures 6 # of untested testcases 39 # of unsupported tests 28 === gfortran Summary === # of expected passes37283 # of unexpected failures1409 # of unexpected successes 1 # of expected failures 13 # of untested testcases 78 # of unsupported tests 72 /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070727 (experimental) I have had a quick look and the cause of failures are quite different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-29 08:59 --- Created an attachment (id=13996) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13996action=view) log and sum files for the tests with -fdefault-integer-8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-07-29 08:39 --- I think I understand what's wrong with my patch now: The stream initialized with init_error_stream was never flushed. I think I'll go with a naked write() call, which is a) simpler b) more robust. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-29 09:24 --- Considering the number of failures to analyse, I think there is need to avoid duplicate efforts. What is the best way to proceed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-07-29 09:47 --- (In reply to comment #8) Considering the number of failures to analyse, I think there is need to avoid duplicate efforts. What is the best way to proceed? I've started a x86_64-linux testsuite with -fdefault-integer-8, so that we can split problems due to endianness from other problems. We'll then see how many fall into each category. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 10:01 --- Subject: Bug 32879 Author: dfranke Date: Sun Jul 29 10:01:27 2007 New Revision: 127037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127037 Log: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32879 * intrinsic.texi (IRAND, RAND, RANDOM_NUMBER): Document algorithm used for random number generator. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:
--- Comment #4 from doko at gcc dot gnu dot org 2007-07-29 10:10 --- Subject: Bug 32929 Author: doko Date: Sun Jul 29 10:09:54 2007 New Revision: 127038 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127038 Log: 2007-07-29 H.J. Lu [EMAIL PROTECTED] PR libgcj/32929 * aclocal.m4: Regenerated. * configure: Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/aclocal.m4 trunk/libjava/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32929
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-29 10:49 --- Subject: Bug 32879 Author: dfranke Date: Sun Jul 29 10:49:11 2007 New Revision: 127042 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127042 Log: 2007-07-29 Daniel Franke [EMAIL PROTECTED] Backport from trunk: 2007-07-29 Daniel Franke [EMAIL PROTECTED] * invoke.texi: Removed -w from option summary. 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32879 * intrinsic.texi (IRAND, RAND, RANDOM_NUMBER): Document algorithm used for random number generator. 2007-07-13 Daniel Franke [EMAIL PROTECTED] * invoke.texi: Unified upper- and lower-case in menus. (-w, -W): Removed, documented by gcc. * intrinsic.texi: Unified Class-section entries, added subroutine/function warning where appropiate. 2007-05-01 Daniel Franke [EMAIL PROTECTED] * intrinsic.texi (MVBITS): Changed class to elemental subroutine. (RANDOM_NUMBER): Changed class to subroutine. (HUGE, TINY): Changed class to inquiry function. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi branches/gcc-4_2-branch/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-29 10:50 --- Documented in 4.2 and trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-29 11:09 --- The following test cases fail only with -m64, but not, or differently, with -m32. FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os execution test FAIL: gfortran.dg/c_assoc.f90 -O0 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O1 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O2 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -Os (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O0 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O0 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O1 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O1 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O2 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O2 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -Os (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -Os (test for excess errors) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (test for excess errors) 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #12 from dominiq at lps dot ens dot fr 2007-07-29 11:11 --- Created an attachment (id=13998) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13998action=view) test case failing with -m32, but not, or differently, with -m64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-29 11:21 --- (In reply to comment #7) (In reply to comment #3) This is OK to commit. FX, In developing the testcase, I found out that this version of the patch is wrong - change 'f=0' to 'f=42' to see what I mean (look at the last line). The loop should be unity based and then it works fine. I will commit after regtesting. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-29 11:08 --- Created an attachment (id=13997) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13997action=view) Failures on PPC Darwin8 common to -m32 and -m64 I attached the reduced list of the test cases failing with -m32 or -m64. I have kept the first instance only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-07-29 11:19 --- From your testresults, Dominique, I see the following testcases ICE: gfortran.dg/altreturn_5.f90 gfortran.dg/associated_2.f90 gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/forall_4.f90 gfortran.dg/pointer_function_actual_1.f90 gfortran.dg/ret_pointer_1.f90 gfortran.dg/where_operator_assign_2.f90 gfortran.fortran-torture/compile/pr32417.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 We know about gfortran.fortran-torture/compile/pr32417.f90 (PR 32527, a tree-optimization bug). My x86_64-linux with -m32 -fdefault-integer-8 revealed the following ICES: gfortran.dg/altreturn_5.f90 gfortran.dg/pointer_function_actual_1.f90 gfortran.fortran-torture/compile/pr32417.f90 gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 So, I'm going to investigate and report altreturn_5.f90, pointer_function_actual_1.f90 and intrinsic_set_exponent.f90. If you could please find some time to report the other ones: gfortran.dg/associated_2.f90 gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/forall_4.f90 gfortran.dg/ret_pointer_1.f90 gfortran.dg/where_operator_assign_2.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 I think beginning with ICEs is a worthly choice. The way to track them down is to reduce the testcase to its bare minimum, note the exact error message and obtain a gdb backtrace. If you need help with the latest step, we can arrange an IRC meeting so that I can help you (send me a private mail). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-29 11:44 --- I have already started to investigate gfortran.dg/forall_4.f90. With -m32 it does not ICE but abort due to the line forall (i=1:n, .not. s(i)) a(i) = i the '.not.' seems to be the problem (the corresonding output is '1 2 3 4'). With -m64 I got the ICE. The following gdb session gives: (gdb) run -fdefault-integer-8 -m64 forall_4_db.f90 Starting program: /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 -fdefault-integer-8 -m64 forall_4_db.f90 Reading symbols for shared libraries ..++++. done foot MAIN__ w t forall_4_db.f90: In function 'MAIN__': forall_4_db.f90:39: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:706 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. (gdb) backtrace No stack. As a side question, this PR has open some kind of Pandora box in which some failures are directly related to this PR, but probably many others are not. Would not it be wise to open a meta bug for -fdefault-integer-8 and different PR for unrelated failures? For instance, it seems that forall_4 could be a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #18 from dje at watson dot ibm dot com 2007-07-29 11:57 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver at kam dot mff dot cuni dot cz writes: it's on ppc-linux. rakdver I mean, I did the testing on ppc-linux; it is possible that there is rakdver another misscompilation on ppc64-linux, though. The target in the PR says powerpc64-linux, which is what confused Andrew and me. There is a valid mode of Altivec programming using builtins and asms that does not require the Altivec ABI. That is what -maltivec supports. I suspect that -ftree-vectorize should enable -mabi=altivec by default on PowerPC. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-29 12:21 --- gfortran.dg/associated_2.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 ICE with the same kind of error (cannot get any backtrace): associated_2_db.f90: In function 'test1': associated_2_db.f90:21: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 intrinsic_associated(_2)?_db.f90: In function 'MAIN__': intrinsic_associated(_2)?_db.f90:15: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libstdc++/32908] Miss lexicographical_compare random access override
-- pcarlini at suse dot de changed: What|Removed |Added CC|rakdver at kam dot mff dot | |cuni dot cz | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-29 12:28:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #16 from dominiq at lps dot ens dot fr 2007-07-29 12:33 --- gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/ret_pointer_1.f90 ICE as associated_2_db: bounds_check_5_db.f90:16: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 gfortran.dg/where_operator_assign_2.f90 ICE with -m64 and the output aborts with -m32, as forall_4.f90: where_operator_assign_2_db.f90:86: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:707 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-07-29 12:44 --- (In reply to comment #14) Program exited with code 04. (gdb) backtrace No stack. You need to backtrace f951 (which is the compiler proper) instead of gfortran (which is only the driver). Use gfortran -v instead of gfortran in your normal compile command, and it will tell you what options f951 is invoked with (there usually are a lot of those). Then, run this f951 command-line under gdb, and you will have backtrace. If the ICE is not due to a segfault, but rather to a failed GCC assertion in the source, you might want to set a breakpoint on fancy_abort and get a backtrace when this function is called. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #18 from dominiq at lps dot ens dot fr 2007-07-29 12:59 --- You need to backtrace f951 Yes indeed: I did gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 I have also noticed that I don't have any entry for today in~/Library/Logs/CrashReporter/, while I have some from running the testsuite (in OSX the backtraces are usually recorded in this subdirectory). Something wierd here. The situation does depend on the version of gfortran I am using (native build or through Fink). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32881] PURE attribute escapes from contained procedure
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 13:01 --- This is accepted: $ cat pr32881.f90 program foo integer :: i = 42 print *, bar() contains pure integer function bar () bar = i end function end program -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #20 from dominiq at lps dot ens dot fr 2007-07-29 13:26 --- And did you set a breakpoint on fancy_abort? If it has to be done explicitely, the answer is no. Doing it I get: (gdb) break fancy_abort Breakpoint 1 at 0xbf4ec: file ../../gcc-4.3-20070727/gcc/diagnostic.c, line 655. (gdb) run -fdefault-integer-8 -m64 forall_4_db.f90 Starting program: /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 -fdefault-integer-8 -m64 forall_4_db.f90 Reading symbols for shared libraries ..++++. done foot MAIN__ w t Breakpoint 1, fancy_abort (file=0x6e168c ../../gcc-4.3-20070727/gcc/emit-rtl.c, line=706, function=0x71682c gen_rtx_SUBREG) at ../../gcc-4.3-20070727/gcc/diagnostic.c:655 655 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) backtrace #0 fancy_abort (file=0x6e168c ../../gcc-4.3-20070727/gcc/emit-rtl.c, line=706, function=0x71682c gen_rtx_SUBREG) at ../../gcc-4.3-20070727/gcc/diagnostic.c:655 #1 0x002035c8 in gen_rtx_SUBREG (mode=SImode, reg=0x436c73d0, offset=0) at ../../gcc-4.3-20070727/gcc/emit-rtl.c:706 #2 0x00289b58 in expand_binop (mode=QImode, binoptab=0x4362c800, op0=0x436c73d0, op1=0x4360dbc0, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at ../../gcc-4.3-20070727/gcc/optabs.c:1531 #3 0x0021d824 in expand_expr_real_1 (exp=0x436b66a0, target=0x0, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:8803 #4 0x0022c2ec in expand_expr_real (exp=0x436b66a0, target=0x0, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6902 #5 0x00220b38 in expand_expr_real_1 (exp=0x436d0280, target=0x436c73b0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:7960 #6 0x0022c2ec in expand_expr_real (exp=0x436d0280, target=0x436c73b0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6902 #7 0x00232cec in store_expr (exp=0x436d0280, target=0x436d2100, call_param_p=0, nontemporal=208 'Ð') at ../../gcc-4.3-20070727/gcc/expr.c:4456 #8 0x00234ca0 in expand_assignment (to=0x436b1000, from=0x436b66a0, nontemporal=0 '\0') at ../../gcc-4.3-20070727/gcc/expr.c:4308 #9 0x0021afc8 in expand_expr_real_1 (exp=0x436b0200, target=0x436b1000, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:8921 #10 0x0022c450 in expand_expr_real (exp=0x436b0200, target=0x4360dbb0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6896 #11 0x004b1488 in expand_expr_stmt (exp=0x436b0200) at ../../gcc-4.3-20070727/gcc/expr.h:503 #12 0x004e57c8 in expand_gimple_basic_block (bb=0x436bcdc0) at ../../gcc-4.3-20070727/gcc/cfgexpand.c:1614 #13 0x004e69dc in tree_expand_cfg () at ../../gcc-4.3-20070727/gcc/cfgexpand.c:1921 #14 0x00291b90 in execute_one_pass (pass=0x80cd00) at ../../gcc-4.3-20070727/gcc/passes.c:1124 #15 0x00291db0 in execute_pass_list (pass=0x80cd00) at ../../gcc-4.3-20070727/gcc/passes.c:1177 #16 0x002ee27c in tree_rest_of_compilation (fndecl=0x43695880) at ../../gcc-4.3-20070727/gcc/tree-optimize.c:405 #17 0x001a02c4 in cgraph_expand_function (node=0x4360bd00) at ../../gcc-4.3-20070727/gcc/cgraphunit.c:1072 #18 0x001a1900 in cgraph_assemble_pending_functions () at ../../gcc-4.3-20070727/gcc/cgraphunit.c:435 #19 0x001a1ddc in cgraph_finalize_function (decl=0x43695880, nested=0 '\0') at ../../gcc-4.3-20070727/gcc/cgraphunit.c:552 #20 0x00094998 in gfc_generate_function_code (ns=0x436aaba0) at ../../gcc-4.3-20070727/gcc/fortran/trans-decl.c:3407 #21 0x00050a8c in gfc_parse_file () at ../../gcc-4.3-20070727/gcc/fortran/parse.c:3287 #22 0x000774a4 in gfc_be_parse_file (set_yydebug=7214732) at ../../gcc-4.3-20070727/gcc/fortran/f95-lang.c:301 #23 0x0011cefc in toplev_main (argc=8365508, argv=0x431070b0) at ../../gcc-4.3-20070727/gcc/toplev.c:1043 #24 0x2330 in _start () #25 0x2034 in start () The old dog has learnt a new trick!-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-07-29 13:11 --- (In reply to comment #18) gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 And did you set a breakpoint on fancy_abort? ICE can be due either to GCC catching a segfault signal (in which case, GDB intercepts the signal first and you can ask for a backtrace) or to a failed internal consistency check (in which case, fancy_abort() is called, prints the error message, and GCC ends without crashing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-29 14:18 --- Subject: Bug 32906 Author: dfranke Date: Sun Jul 29 14:17:59 2007 New Revision: 127043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127043 Log: gcc/fortran: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32906 * resolve.c (resolve_fl_parameter): Check for constant shape arrays, adjusted error message. gcc/testsuite: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32906 * gfortran.dg/shape_1.f90: Adjust error message. * gfortran.dg/parameter_array_ref_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/shape_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 --- Thanks for the report! Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.1 4.3.0 |4.1.2 4.2.1 Known to work||4.3.0 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 --- Closing, take II. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:45 --- Fixed on trunk with correction to be unity rather than zero based. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #21 from tkoenig at gcc dot gnu dot org 2007-07-29 14:57 --- As a side question, this PR has open some kind of Pandora box in which some failures are directly related to this PR, but probably many others are not. Would not it be wise to open a meta bug for -fdefault-integer-8 and different PR for unrelated failures? Definitely. Let's make this one the meta-bug and hang the individual bugs off it. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |meta-bug Summary|-fdefault-integer-8 and the |[Meta-bug] -fdefault- |library |integer-8 issues http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 --- Subject: Bug 31211 Author: pault Date: Sun Jul 29 14:44:03 2007 New Revision: 127044 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044 Log: 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * trans-expr.c (gfc_conv_expr_reference): Add block for case of scalar pointer functions so that NULL result is correctly handled. PR fortran/32682 *trans-array.c (gfc_trans_array_constructor): On detecting a multi-dimensional parameter array, set the loop limits. 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * gfortran.dg/actual_pointer_function_1.f90: New test. PR fortran/32682 * gfortran.dg/scalarize_parameter_array_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 --- Subject: Bug 32682 Author: pault Date: Sun Jul 29 14:44:03 2007 New Revision: 127044 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044 Log: 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * trans-expr.c (gfc_conv_expr_reference): Add block for case of scalar pointer functions so that NULL result is correctly handled. PR fortran/32682 *trans-array.c (gfc_trans_array_constructor): On detecting a multi-dimensional parameter array, set the loop limits. 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * gfortran.dg/actual_pointer_function_1.f90: New test. PR fortran/32682 * gfortran.dg/scalarize_parameter_array_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:47 --- Fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug libstdc++/32908] Miss lexicographical_compare random access override
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-29 15:14 --- I would be curious to hear from Zdenek: is there something that could be done in the loop optimizer dealing generally with this common patterns? Not at the moment. It would be possible to implement this optimization, but most likely it would not be very useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libstdc++/32908] Miss lexicographical_compare random access override
--- Comment #3 from pcarlini at suse dot de 2007-07-29 15:21 --- Ok, Zdenek, thanks a lot anyway... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #8 from jb at gcc dot gnu dot org 2007-07-29 15:58 --- I had a look at your patch, and one thing which looks worrying is the use of sprintf all over the place. That's just a recipe for buffer overflows, especially when combined with %s formatting. I think Tobi's suggestion to use libiberty dyn-string is good. (In reply to comment #6) There are also a few other issues with the incomplete patch. vsnprintf can be replaced by __builtin_vsnprintf on systems where it isn't available. Doesn't the compiler automatically take care of using builtin_vsnprintf? (In reply to comment #7) I think I understand what's wrong with my patch now: The stream initialized with init_error_stream was never flushed. I think I'll go with a naked write() call, which is a) simpler b) more robust. This will mess up the indices in unix_stream, no? I suppose you could get around that by flushing before writing, but that's the cardinal sin writing an I/O library: Never, ever, ever flush to fix a bug. And yes, we have committed this sin in multiple places in libgfortran. :( More generally, see PR25561 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug target/32871] Bad optimasation - Gcc is pushing to many registers
--- Comment #1 from info at umfragen-service dot de 2007-07-29 16:12 --- Konsole: = [EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make begin * Individual makefile for AvrLiveCD * Avr-Gcc version: avr-gcc (GCC) 4.1.2 Copyright (C) 2006 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. * --- avr-size -d main.elf -t avr-size: 'main.elf': No such file 0 0 0 0 0 (TOTALS) Compiling: main.c avr-gcc -c -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L /usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst -I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o main.c:32:2: warning: no newline at end of file Linking: main.elf avr-gcc -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L /usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.o -I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref Creating load file for Flash: main.hex avr-objcopy -O ihex -R .eeprom main.elf main.hex Creating load file for EEPROM: main.eep avr-objcopy -j .eeprom --set-section-flags .eeprom=alloc,load \ --change-section-lma .eeprom=0 -O ihex main.elf main.eep avr-objcopy: there are no sections to be copied! avr-objcopy: --change-section-lma .eeprom=0x never used make: [main.eep] Error 1 (ignored) Creating Extended Listing: main.lss avr-objdump -h -S main.elf main.lss Creating Symbol Table: main.sym avr-nm -n main.elf main.sym avr-size -d main.elf -t textdata bss dec hex filename 228 0 0 228 e4 main.elf 228 0 0 228 e4 (TOTALS) end [EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make main.i avr-gcc -E -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L /usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst -I/usr/local/bin/avr/include/ -std=gnu99 main.c -o main.i main.c:32:2: warning: no newline at end of file [EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make main.s avr-gcc -S -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L /usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst -I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.s.d main.c -o main.s main.c:32:2: warning: no newline at end of file [EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# === main.c === //General Avrincludes #include avr/io.h long foo(long a, long b, long c, uint8_t d){ if(d){ return a+b; }else{ return a-c; } } long foo_rec(long a){ if(a==4){ return foo_rec(a-1)+2; } return 1; } long foo_rec2(long a, long b){ if(!b){ return foo_rec2(a+2,b+4); }else{ return a+b+4; } } int main(void){ return 0; } The preprocessed file: # 1 main.c # 1 /mnt/sda1_removable/avr/gcc_schlecht// # 1 built-in # 1 command line # 1 main.c # 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/io.h 1 3 # 87 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/io.h 3 # 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/sfr_defs.h 1 3 # 126 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/sfr_defs.h 3 # 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/inttypes.h 1 3 # 37 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/inttypes.h 3 # 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 1 3 # 121 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3 typedef int int8_t __attribute__((__mode__(__QI__))); typedef unsigned int uint8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__ ((__mode__ (__HI__))); typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__))); typedef int int32_t __attribute__ ((__mode__ (__SI__))); typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__))); typedef int int64_t __attribute__((__mode__(__DI__))); typedef unsigned int uint64_t __attribute__((__mode__(__DI__))); # 142 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3 typedef int16_t intptr_t; typedef uint16_t uintptr_t; # 159 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3 typedef int8_t int_least8_t; typedef uint8_t uint_least8_t; typedef int16_t
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-07-29 16:33 --- Created an attachment (id=13999) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13999action=view) Patch (current status) This patch is currently bootstrapping on my machine. Let's see how it works. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #13995|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/32931] New: FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64
I think the following is different enough from PR32770 to justify a new PR. As reported, gfortran.dg/forall_4.f90 and gfortran.dg/where_operator_assign_2.f90 give an ICE when compiled on darwin8 with both -fdefault-integer-8 and -m64 (see PR32770#20) fo a backtrace. The following reduced codes yield the same ICE: integer, parameter :: n = 4 integer :: i, a(n) logical :: s(n) s = .True. a = 0 forall (i=1:n, .not. s(i)) a(i) = i if (any (a .ne. (/1,0,0,4/))) call abort () end and module global type :: a integer :: b integer :: c end type a interface assignment(=) module procedure a_to_a end interface interface operator(.ne.) module procedure a_ne_a end interface type(a) :: x(4), y(4), z(4), u(4, 4) logical :: l1(4), t = .true., f= .false. contains !** elemental subroutine a_to_a (m, n) type(a), intent(in) :: n type(a), intent(out) :: m m%b = n%b + 1 m%c = n%c end subroutine a_to_a !** elemental logical function a_ne_a (m, n) type(a), intent(in) :: n type(a), intent(in) :: m a_ne_a = (m%b .ne. n%b) .or. (m%c .ne. n%c) end function a_ne_a !** elemental function foo (m) type(a) :: foo type(a), intent(in) :: m foo%b = 0 foo%c = m%c end function foo end module global !** program test use global x = (/a (0, 1),a (0, 2),a (0, 3),a (0, 4)/) y = x z = x l1 = (/t, f, f, t/) call test_where_3 if (any (y .ne. (/a (1, 0),a (1, 2),a (1, 3),a (1, 0)/))) call abort () ! y = x ! call test_where_forall_1 ! if (any (u(4, :) .ne. (/a (1, 4),a (2, 2),a (2, 3),a (1, 4)/))) call abort () contains !** subroutine test_where_3! Test a simple WHERE with a function assignment where (.not. l1) y = foo (x) end subroutine test_where_3 !** ! subroutine test_where_forall_1 ! Test a WHERE in a FORALL block !forall (i = 1:4) ! where (.not. l1) !u(i, :) = x ! elsewhere !u(i, :) = a(0, i) ! endwhere !end forall ! end subroutine test_where_forall_1 !** end program test The commented FORALL also gives the same ICE. However the simplified version of the last code: program test integer :: x(4), y(4), z(4), u(4, 4) logical :: l1(4), t = .true., f= .false. x = (/ 1, 2, 3, 4/) l1 = (/t, f, f, t/) y = 0 where (.not. l1) y = x if (any (y .ne. (/0, 2, 3, 0/))) call abort () end program test compiles and pass. Note also that the problem is also present in gcc 4.2.1. -- Summary: FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64 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 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug web/32927] Online installation instructions only for mainline
--- Comment #2 from ammonton at cc dot helsinki dot fi 2007-07-29 17:53 --- The INSTALL directory only has a README saying the instructions are generated from gcc/doc/install.texi and the install.texi2html script in that directory complains about a missing file gcc-vers.texi which I gather is generated when building the compiler. If you need instructions on how to install the installation instructions something is wrong, IMO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
[Bug testsuite/32932] New: ssp-2.c fails when previous gcc-4.3 installation is visible
/usr/local/gcc43/lib/gcc/i686-pc-cygwin/4.3.0/../../../libssp.a(ssp.o):ssp.c:(.t ext+0x190): multiple definition of `___stack_chk_fail'^M /cygdrive/c/Temp/ccrBTHWE.o:ssp-2.c:(.text+0x0): first defined here^M collect2: ld returned 1 exit status^M function declaration in testsuite conflicts with function present in libssp.a of previous installation of gcc 4.3 -- Summary: ssp-2.c fails when previous gcc-4.3 installation is visible Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #27 from tprince at computer dot org 2007-07-29 18:00 --- same failure for gcc-4.3 mainline on i686-pc-cygwin -- tprince at computer dot org changed: What|Removed |Added CC||tprince at computer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #10 from patchapp at dberlin dot org 2007-07-29 18:55 --- Subject: Bug number PR 32858 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02070.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/32931] FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-29 19:35 --- Note that the ICEs with -m64 diasppear with -O3, but then both tests fail to execute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01 --- Subject: Bug 32858 Author: tkoenig Date: Sun Jul 29 20:01:45 2007 New Revision: 127049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049 Log: 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * configure.ac: Added checks for presence of stdio.h and stdarg.h. Test presence of vsnprintf(). * configure: Regenerated. * config.h.in: Regenerated. * libgfortran.h: Include stdio.h. Add printf attribute to prototype of runtime_error. Remove prototype for st_sprintf. Add prototype for st_vprintf. * runtime/main.c (store_exec_path): Replace st_sprintf by sprintf. * runtime/error.c (st_sprintf): Remove. (runtime_error): Rewrite as a variadic function. Call st_vprintf(). * intrinsics/pack_generic.c: Output extents of LHS and RHS for bounds error. * io/open.c (new_unit): Replace st_sprintf by sprintf. * io/list_read.c (convert_integer): Likewise. (parse_repeat): Likewise. (read_logical): Likewise. (read_character): Likewise. (parse_real): Likewise. (read_real): Likewise. (check_type): Likewise. (nml_parse_qualifyer): Likewise. (nml_read_obj): Likewise. (nml_get_ojb_data): Likewise. * io/unix.c (init_error_stream): Remove. (tempfile): Replace st_sprintf by sprintf. (st_vprintf): New function. (st_printf): Rewrite to call st_vprintf. * io/transfer.c (require_type): Replace st_sprintf by sprintf. * io/format.c (format_error): Likewise. * io/write.c (nml_write_obj): Likewise. 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * gfortran.dg/pack_bounds_1.f90: Adjust to new error message. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pack_bounds_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/io/format.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01 --- Subject: Bug 30814 Author: tkoenig Date: Sun Jul 29 20:01:45 2007 New Revision: 127049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049 Log: 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * configure.ac: Added checks for presence of stdio.h and stdarg.h. Test presence of vsnprintf(). * configure: Regenerated. * config.h.in: Regenerated. * libgfortran.h: Include stdio.h. Add printf attribute to prototype of runtime_error. Remove prototype for st_sprintf. Add prototype for st_vprintf. * runtime/main.c (store_exec_path): Replace st_sprintf by sprintf. * runtime/error.c (st_sprintf): Remove. (runtime_error): Rewrite as a variadic function. Call st_vprintf(). * intrinsics/pack_generic.c: Output extents of LHS and RHS for bounds error. * io/open.c (new_unit): Replace st_sprintf by sprintf. * io/list_read.c (convert_integer): Likewise. (parse_repeat): Likewise. (read_logical): Likewise. (read_character): Likewise. (parse_real): Likewise. (read_real): Likewise. (check_type): Likewise. (nml_parse_qualifyer): Likewise. (nml_read_obj): Likewise. (nml_get_ojb_data): Likewise. * io/unix.c (init_error_stream): Remove. (tempfile): Replace st_sprintf by sprintf. (st_vprintf): New function. (st_printf): Rewrite to call st_vprintf. * io/transfer.c (require_type): Replace st_sprintf by sprintf. * io/format.c (format_error): Likewise. * io/write.c (nml_write_obj): Likewise. 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * gfortran.dg/pack_bounds_1.f90: Adjust to new error message. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pack_bounds_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/io/format.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug testsuite/32932] ssp-2.c fails when previous gcc-4.3 installation is visible
--- Comment #1 from tprince at computer dot org 2007-07-29 20:15 --- This test is reported failing also by anonymous testers of powerpc-apple-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug middle-end/23845] missed strength reduction costs performance
--- Comment #5 from tprince at computer dot org 2007-07-29 20:57 --- No longer relevant, due to changes in gfortran. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug testsuite/31340] testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
--- Comment #2 from tprince at computer dot org 2007-07-29 20:54 --- The suggested function name change is in mainline, and this resolves the bug. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #8 from tprince at computer dot org 2007-07-29 21:02 --- The patch discussed here was incorporated in mainline, and the failure was last reported 20070420. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug libgcj/30071] make install fails for libjava
--- Comment #6 from andreast at gcc dot gnu dot org 2007-07-29 21:24 --- install-binPROGRAMS: install-toolexeclibLTLIBRARIES 'overwrites' the install-binPROGRAMS generated by automake. So this is a no go. I helped myself with this one: Index: Makefile.am === --- Makefile.am (revision 126962) +++ Makefile.am (working copy) @@ -440,7 +440,7 @@ $(extra_headers) $(srcdir)/java/lang/Object.h $(srcdir)/java/lang/Class.h: @: -install-exec-hook: install-toolexeclibLTLIBRARIES install-libexecsubPROGRAMS +install-exec-hook: install-binPROGRAMS install-toolexeclibLTLIBRARIES install-libexecsubPROGRAMS ## Support for libgcj_bc: dummy shared library used only at link-time. if USE_LIBGCJ_BC ## Install libgcj_bc dummy lib in the target directory. We also need to delete This one is similar to the one Rainer posted and it might not work if one is doing a parallel install. I'll do a test on my farm and see how it behaves on different architectures. Tom mentioned on IRC that it would be a 'go' for the time being. But one has to file a bug on automake. (1.9.6 used here). Will do so. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-29 20:00:01 |2007-07-29 21:24:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30071
[Bug tree-optimization/32919] [4.3 Regression] SSA corruption because of abnormal edges and PRE
--- Comment #3 from drow at gcc dot gnu dot org 2007-07-29 21:34 --- Damn, I couldn't find this bug when I searched for it Saturday morning, so I spent all day reducing the testcase... -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32919
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-07-29 23:23 --- The patch applied in Comment #11 fixes the original test case. The modified test case in Comment #8 is still broken. pr31609-2.f90: In function master.0.j: pr31609-2.f90:10: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:452 I am going to have to leave this to others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug fortran/32933] New: ICE in simplify_subreg with -fdefault-integer-8
Simplification of the ICE with nan_1.f90: $ !cat cat nan_6.f90 program test real :: a if (min(a, 3.0, 2.0) /= 2.0) call abort end program test $ gfortran -fdefault-integer-8 nan_6.f90 nan_6.f90: In function 'MAIN__': nan_6.f90:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This goes away if -ffast-math is specified, so it looks as if the call to __builtin_isnan is causing the trouble. -- Summary: ICE in simplify_subreg with -fdefault-integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 32770 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug middle-end/21137] Convert (a 2) 1 != 0 into a 4 != 0
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug c++/32934] New: No warning when creating a non const derived funtion from a const virtual funciton
Maybe this isn't a bug, but I can't see why this shouldn't at least be a warning since it changes the output of the program... ==C++ Source with B.print not const #include iostream class A { public: virtual char * print() const { return A\n;} virtual ~A(){}; }; class B : public A { public: virtual char * print() { return B\n;} virtual ~B(){}; }; int main () { B b; A a = b; std::cout a.print() b.print(); } [EMAIL PROTECTED]:~/working$ g++ -Wall -o gcc_bug gcc_bug.cpp [EMAIL PROTECTED]:~/working$ ./gcc_bug A B =C++ Source with B.print const= #include iostream class A { public: virtual char * print() const { return A\n;} virtual ~A(){}; }; class B : public A { public: virtual char * print() const { return B\n;} virtual ~B(){}; }; int main () { B b; A a = b; std::cout a.print() b.print(); } [EMAIL PROTECTED]:~/working$ g++ -Wall -o gcc_bug gcc_bug.cpp [EMAIL PROTECTED]:~/working$ ./gcc_bug B B What am I missing? Andrew -- Summary: No warning when creating a non const derived funtion from a const virtual funciton Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: CyrusOmega at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32934
[Bug c++/32934] No warning when creating a non const derived funtion from a const virtual funciton
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-30 02:19 --- Well it is valid as B::print hides A::print. Try doing: #include iostream class A { public: virtual char * print() const { return A\n;} virtual ~A(){}; }; class B : public A { public: virtual char * print() { return B\n;} using A::print; virtual ~B(){}; }; int main () { B b; A a = b; const B b1 = b; std::cout a.print() b1.print(); } Which shows that b1.print will call A::print. If you don't include using A::print, then A::print wil be hidden in B. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32934