http://blog.gmane.org/gmane.comp.gcc.fortran hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gcc.fortran/40962 <pre> Maybe I should change the order, by having _F_DA0 - one never knows where DA_F_0 gets exposed. In principle, it should be a local variable name which isn't seen by anyone (except with debugging symbols). But as the assembler failure showed, it can get escape and be at least visible to the debugger. As local Fortran variable, DA_F_0 cannot be generated as all (g)fortran variable names are converted to lower space; using C binding, one can generate such a name (and also "_F_DA_0"). But that is a global variable should be a different tree decl and, hence, confusingly in the dump but not overlapping. On the other hand, I still do not completely understand why the name leaks to the assembler - thus, I wouldn't rule out anything. Side note: If the assembler supports it, the name has a dot or a $ in the name, which makes clashes even less likely. I have now changed it to: - sprintf (name, "DA" GFC_PREFIX("%d"), serial++); + sprintf (name, GFC_PREFIX("DA%d"), serial++); Thanks for the comment. Tobias </pre> Tobias Burnus 2013-05-22T19:26:31 http://permalink.gmane.org/gmane.comp.gcc.fortran/40959 <pre>Pre-remark: This patch does *not* enable finalization or polymorphic deallocation. * * * Dear all, The attached patch is a bit boring and invasive, but it paves the way to FINAL support. Changes of technical kind: * Changed ABI for CLASS's virtual table (due to _final) - and, hence, it bumps the .mod version * The finalization wrapper is now generated (this should not but might lead to ICEs) * It also causes that the virtual table is now more often generated New feature: _copy no longer deallocates the "dst" argument. Doing so lead to bogus finalization with ALLOCATE (exposed with the pending FINAL patch). As a sideeffect, memset could be removed and CALLOC could be replased by MALLOC (minute performance advantage). In order to keep the deallocation in gfc_trans_class_array_init_assign, there is now a call to the finalization wrapper. Next steps: * Add end-of-scope/intent(out) deallocation for polymorphic arrays * Enable FINAL parsing * Stepwise enabling for polymorphic deallocation/finalization * Fix issues with ELEMENTAL(+optional) with intent(out) * Fix some issues related to intrinsic assignment * Fix fallout of any of those items Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias </pre> Tobias Burnus 2013-05-22T19:02:38 http://permalink.gmane.org/gmane.comp.gcc.fortran/40958 <pre>With one Fortran file, I get the following assembler errors: /tmp/cc28epKK.s:2075: Error: junk `&lt; at &gt;1.2304+16' after expression That's due to the way a temporary variable is generated. While that variable is local to the procedure, the name somehow escapes into the assembler file. The dump looks as follows. static struct foo DA&lt; at &gt;0; static struct universal DA&lt; at &gt;1; static struct universal DA&lt; at &gt;2; ... class.30._data = &amp;DA&lt; at &gt;0.foo_parent.universal.counter; I have now changed the mangling, see attached patch. (The test file uses finalization - hence, I do not include it into the patch. I will include it in the FINAL patch.) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias </pre> Tobias Burnus 2013-05-22T14:20:57 http://permalink.gmane.org/gmane.comp.gcc.fortran/40955 <pre>On Tue, May 21, 2013 at 2:50 AM, Steve Kargl &lt;sgk&lt; at &gt;troutmask.apl.washington.edu&gt; wrote: Thanks. Attached is the patch I committed following 'make pdf' testing. Committed to trunk/4.8 (after Jakub's approval on IRC)/4.7. -- Janne Blomqvist </pre> Janne Blomqvist 2013-05-22T08:41:56 http://permalink.gmane.org/gmane.comp.gcc.fortran/40954 <pre>That's a follow-up the just committed patch - which came too late in some cases. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias </pre> Tobias Burnus 2013-05-21T18:05:50 http://permalink.gmane.org/gmane.comp.gcc.fortran/40948 <pre>Hello world, the attached patch replaces (-1.0)**i with (in C language) (i &amp; 1) == 0 ? 1.0 : 1.0, see PR 57073. I tried doing it in the middle end, see the PR of where these approaches failed. So, rather than not doing the optimization at all, I would rather do it in the Fortran front end. If somebody jumps in with a middle-end solution that works, I would withdraw this patch. Regression-tested on trunk. OK? Thomas 2013-05-19 Thomas Koenig &lt;tkoenig&lt; at &gt;gcc.gnu.org&gt; PR fortran/57073 * trans-expr.c: Simplify (-1.0)**i to (i &amp; 1) == 0 ? 1.0 : -1.0. 2013-05-19 Thomas Koenig &lt;tkoenig&lt; at &gt;gcc.gnu.org&gt; PR fortran/57073 * gfortran.dg/power_6.f90: New test. </pre> Thomas Koenig 2013-05-19T14:55:16 http://permalink.gmane.org/gmane.comp.gcc.fortran/40947 <pre>* PING * Patches in this trilogy: * http://gcc.gnu.org/ml/fortran/2013-05/msg00048.html - COMMON * http://gcc.gnu.org/ml/fortran/2013-05/msg00051.html - PROCEDURE * http://gcc.gnu.org/ml/fortran/2013-05/msg00056.html - more on bind label handling Especially the first one should be rather simple to review. Tobias On May 13, 2013 Tobias Burnus wrote: </pre> Tobias Burnus 2013-05-18T16:29:14 http://permalink.gmane.org/gmane.comp.gcc.fortran/40946 <pre>On Fri, May 17, 2013 at 5:15 PM, Angelo Graziosi &lt;angelo.graziosi&lt; at &gt;alice.it&gt; wrote: Hi, since seed is an allocatable array, it is automatically deallocated when it goes out of scope, per the Fortran standard. IIRC this was one of the relatively few changes in Fortran 95 compared to Fortran 90. -- Janne Blomqvist </pre> Janne Blomqvist 2013-05-17T19:20:29 http://permalink.gmane.org/gmane.comp.gcc.fortran/40945 <pre>Ciao Janne, Janne Blomqvist wrote: using /dev/urandom is very appealing! Your example shouldn't call "deallocate(seed)" after "call random_seed(put=seed)"? Something like this: ... end if call random_seed(put=seed) deallocate(seed) end subroutine rseed end module rseed_rand Ciao, Angelo. </pre> Angelo Graziosi 2013-05-17T14:15:27 http://permalink.gmane.org/gmane.comp.gcc.fortran/40944 <pre>Hi, the example we provide for the usage of the random_seed intrinsic could be better. At least one user has already been tripped over by the fact that on some targets the first call to system_clock returns 0, resulting in a poor seed. Below is an improved(?!) example program. Ok for trunk/4.8/4.7? (Changelog + patch is of course trivial once there is agreement on the code itself) ! Seed the random generator with some random input module rseed_rand contains subroutine rseed() implicit none integer, allocatable :: seed(:) integer :: i, n, un, istat, dt(8), pid, t(2), s integer(8) :: count, tms call random_seed(size = n) allocate(seed(n)) ! First try if the OS provides a random number generator open(newunit=un, file="/dev/urandom", access="stream", &amp; form="unformatted", iostat=istat) if (istat == 0) then read(un) seed close(un) else ! Fallback to XOR:ing the current time and pid. The PID is ! useful in case one launches multiple instances of the same ! program in parallel. call system_clock(count) if (count /= 0) then t = transfer(count, t) else call date_and_time(values=dt) tms = (dt(1) - 1970) * 365_8 * 24 * 60 * 60 * 1000 &amp; + dt(2) * 31_8 * 24 * 60 * 60 * 1000 &amp; + dt(3) * 24 * 60 * 60 * 60 * 1000 &amp; + dt(5) * 60 * 60 * 1000 &amp; + dt(6) * 60 * 1000 + dt(7) * 1000 &amp; + dt(8) t = transfer(tms, t) end if s = ieor(t(1), t(2)) pid = getpid() s = ieor(s, pid) if (n &gt;= 3) then seed(1) = t(1) seed(2) = t(2) seed(3) = pid if (n &gt; 3) then seed(4:) = s + 37 * (/ (i, i = 0, n - 4) /) end if else seed = s + 37 * (/ (i, i = 0, n - 1 ) /) end if end if call random_seed(put=seed) end subroutine rseed end module rseed_rand -- Janne Blomqvist </pre> Janne Blomqvist 2013-05-17T12:18:01 http://permalink.gmane.org/gmane.comp.gcc.fortran/40943 <pre>Am 17.05.2013 05:22, schrieb Bud Davis: Missing blank after the comma. Indentation is wrong. (As a friend of hyphens, I would add one between self and referential, but it is also fine without.) Please add "! PR fortran/50405" as comment. Instead of dg-prune-output, you could also use: '! { dg-options "" }'. That will override the default setting, i.e. it removes the "-pedantic". OK and thanks for the patch! Tobias PS: Nice that you are back to (casual) gfortran development. </pre> Tobias Burnus 2013-05-17T07:19:49 http://permalink.gmane.org/gmane.comp.gcc.fortran/40942 <pre>Followup (and depending on) to the C binding patches for * COMMON: http://gcc.gnu.org/ml/fortran/2013-05/msg00048.html * Procedures: http://gcc.gnu.org/ml/fortran/2013-05/msg00051.html which honour Fortran 2008, where the Fortran name is no longer a global identifier if a binding name has been specified. The main reason for this patch is a build failure of Open MPI (requires !gcc$ attributes no_arg_check, i.e. it only affects GCC 4.9). Open MPI uses somethine like: interface subroutine pmpi_something() bind(C,name="MPI_something") ... and in a different module: interface subroutine mpi_something() bind(C,name="MPI_something") ... Currently, gfortran rejects it because it only permits one definition/declaration per translation unit. However, there is no reason why multiple INTERFACE blocks shouldn't be permitted. Remarks: a) Better argument checks if definition and declaration are in the same file. (see INTENT patch in a test case) b) Currently, no check is done regarding the characteristic of procedure declarations. Of course, the declaration has to be compatible with the C procedure. However, there seems to be the wish* to permit compatible input - even if the Fortran characteristic is different. For instance "int *" takes both a scalar integer ("int i; f(&amp;i)") and arrays ("int i[5]; f(i)"). Or also popular according to the PRs: Taking a C_LOC or an integer(c_intptr_t). (* Seemingly, also J3 and/or WG5 discussed this (plenum? subgroups?) and they had the permit it. However, finding some official document is difficult.) I was wondering for a while what should be permitted and what shouldn't, but I have now decided to put that completely into the hands of the user. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias </pre> Tobias Burnus 2013-05-17T06:45:18 http://permalink.gmane.org/gmane.comp.gcc.fortran/40941 <pre>Not to much to add beyond the title and the patch. The test file fails before (eventually, when you run out of stack) and passes after the patch is applied.  No new testsuite failures. --bud Index: gcc/gcc/fortran/resolve.c =================================================================== --- gcc/gcc/fortran/resolve.c    (revision 198955) +++ gcc/gcc/fortran/resolve.c    (working copy) &lt; at &gt;&lt; at &gt; -306,6 +306,14 &lt; at &gt;&lt; at &gt;            &amp;&amp; !resolve_procedure_interface (sym))     return; +      if (strcmp (proc-&gt;name,sym-&gt;name) == 0) +        { +       gfc_error ("Self referential argument " +       "'%s' at %L is not allowed", sym-&gt;name, +       &amp;proc-&gt;declared_at); +       return; +        } +        if (sym-&gt;attr.if_source != IFSRC_UNKNOWN)     resolve_formal_arglist (sym); !{ dg-do compile } ! submitted by zeccav&lt; at &gt;gmail.com !{ dg-prune-output "Obsolescent feature: Statement function at" } f(f) = 0 ! { dg-error "Self referential argument" } end 2013-05-17  Bud Davis  &lt;jmdavis&lt; at &gt;link.com&gt;         PR fortran/50405         resolve.c (resolve_formal_arglist): Detect error when an argument         has the same name as the function. </pre> Bud Davis 2013-05-17T03:22:48 http://permalink.gmane.org/gmane.comp.gcc.fortran/40940 <pre>The following causes an ICE with gfortran 4.9.0 r198983: module t type :: c end type c type(c), target :: cd class(c), public, pointer :: cc =&gt; cd end module t $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown- linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib --with- gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.9.0 20130516 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o bug.F90:7:0: internal compiler error: in gfc_conv_structure, at fortran/trans- expr.c:6027 class(c), public, pointer :: cc =&gt; cd ^ 0x5be449 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/trans-expr.c:6027 0x5be610 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:5606 0x5a8cd6 gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.c:1500 0x5aeb02 gfc_create_module_variable ../../gcc-trunk/gcc/fortran/trans-decl.c:4144 0x572ed3 do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:3571 0x5aef52 gfc_generate_module_vars(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:4543 0x588ec1 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:1738 0x547687 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4456 0x547687 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4666 0x583a25 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See &lt;http://gcc.gnu.org/bugs.html&gt; for instructions. I've opened PR 57306 for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 Thanks, Andrew </pre> Andrew Benson 2013-05-16T18:53:39 http://permalink.gmane.org/gmane.comp.gcc.fortran/40939 <pre>Hello, There is PR57297 that has been reported today and looks related. I suspect class symbols don't get the target attributes as they should, so that the underlying data get a different type. I have just posted a tentative patch to the PR. Maybe it works... Mikael </pre> Mikael Morin 2013-05-15T21:44:47 http://permalink.gmane.org/gmane.comp.gcc.fortran/40933 <pre> I think that part is okay - but as you mentioned TYPE(*) in your last email: That doesn't work; I think compare_type_rank should be made asymmetrical in this regard (ditto for "!gcc$ attributes no_arg_check"). Thus, could you fix that part as well? I am fine with that suggestion. Regarding the your other email in this thread: I was indeed talking about that part of the proc-pointer-assignment check. Tobias </pre> Tobias Burnus 2013-05-12T16:18:02 http://permalink.gmane.org/gmane.comp.gcc.fortran/40931 <pre> Ok, so: How about the attached patch as a simple &amp; backportable fix for the regression? (Ok for trunk/4.8/4.7?) I suggest the rest (i.e. splitting up compare_type_rank, improving error messages, etc) should be done in a follow-up patch on trunk only. (I might even volunteer do to this once I find the time ...) Cheers, Janus </pre> Janus Weil 2013-05-11T15:58:51 http://permalink.gmane.org/gmane.comp.gcc.fortran/40930 <pre> I know that equation.com makes it simple to use GCC - on the other hand, I do recall that I once tried to trace a reported internal-compiler error (segfault), which turned out occur only with the equation.com build but not with the builds of the MinGW-w64 project. Hence, you could try another build - e.g. those from MinGW-w64 project itself. (Admittedly, their download website is not very well structured.) The best build I found browsing their site is: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/ Tobias </pre> Tobias Burnus 2013-05-10T21:36:28 http://permalink.gmane.org/gmane.comp.gcc.fortran/40929 <pre> Without see source or knowing what changes equation.com may have made to the compiler, it is almost impossible to make any guess as to the issue. Have you ask equation.com what they may have changes in the compiler to cause such an explosion in memory usage? </pre> Steve Kargl 2013-05-10T21:16:38 http://permalink.gmane.org/gmane.comp.gcc.fortran/40928 <pre>Greetings all, I am running into strange memory issues that I don't know the cause of. I'll gladly put together a short test case, assuming that I can reproduce the behavior. Briefly, when I compile the same chunk of code and run it on the identical test case, I obtain the following memory usage during the run: 4.7.2 : 25MB committed 4.8.0 2013.02.17 (experimental) : 1898MB committed 4.9.0 2013.04.21 (experimental) : 1898MB committed gfortran versions mentioned above are the 64-bit MinGW versions, compiled by equation.com. Compilation flags were identical for each gfortran version. Again, I'd love to help out by generating a short test case, but I don't even know where to begin. Let me know if you'd like more specifics or if you have suggestions regarding the apparent memory use increase. Thanks, - Steve </pre> Steve Westenbroek 2013-05-10T21:00:17 http://permalink.gmane.org/gmane.comp.gcc.fortran/40927 <pre>So, I was tracking down a bug in gfortran.dg/select_type_4.f90 and it turns out that if I reschedule (I do this after loop optimizations and before web) the code, the code then fails at runtime. If I compile with -fno-strict-aliasing, the problem goes away. The change is to hoist a load up to the top of the basic block. I believe that that alias information is likely wrong. insn 231 is the hoisted load. I'm hoping a hand review of the source by a fortran expert and the alias sets involved { , 3, 12} can identify the part that went wrong. (code_label 218 213 219 14 21 "" [1 uses]) (note 219 218 231 14 [bb 14] NOTE_INSN_BASIC_BLOCK) (insn 231 219 232 14 (set (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ]) (mem/c:DI (plus:DI (reg/f:DI 1053) (const_int 8 [0x8])) [12 MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 S8 A64])) t.f90:37 5 {*load} (expr_list:REG_DEAD (reg/f:DI 1053) (nil))) (insn 232 231 220 14 (set (mem:DI (plus:DI (reg/v/f:DI 602 [ integer_node ]) (const_int 8 [0x8])) [3 MEM[(struct node_type *)integer_node_19].next+8 S8 A64]) (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ])) t.f90:37 65 {*store} (expr_list:REG_DEAD (reg/v/f:DI 602 [ integer_node ]) (nil))) (insn 220 232 247 14 (set (mem/f/c:DI (plus:DI (reg/f:DI 2134 IN2) (const_int -560 [0xfffffffffffffdd0])) [3 MEM[(struct __class_poly_list_Node_type_p *)&amp;node]+0 S8 A128]) (reg/f:DI 603 [ node ])) t.f90:37 65 {*store} (nil)) (insn 247 220 774 14 (set (mem/c:DI (plus:DI (reg/f:DI 1046) (const_int 8 [0x8])) [3 list.tail+8 S8 A64]) (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ])) t.f90:38 65 {*store} (expr_list:REG_DEAD (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ]) (nil))) (insn 774 247 248 14 (set (reg/f:DI 735) (reg/f:DI 1045)) t.f90:37 3335 {mymovdi} (expr_list:REG_EQUAL (symbol_ref:DI ("__poly_list_MOD___vtab_poly_list_Node_type") [flags 0x2] &lt;var_decl 0x7fc2cfd4e720 __vtab_poly_list_Node_type&gt;) (nil))) (insn 248 774 224 14 (set (reg:DI 3678 $r4) (const_int 24 [0x18])) t.f90:136 3181 {mymovdi} (nil)) (insn 224 248 245 14 (set (mem/f/c:DI (plus:DI (reg/f:DI 2134 IN2) (const_int -552 [0xfffffffffffffdd8])) [3 MEM[(struct __class_poly_list_Node_type_p *)&amp;node + 8B]+0 S8 A64]) (reg/f:DI 1045)) t.f90:37 65 {*store} (nil)) (insn 245 224 812 14 (set (mem/c:DI (plus:DI (reg/f:DI 1057) (const_int 16 [0x10])) [3 list.tail+0 S8 A64]) (reg/f:DI 603 [ node ])) t.f90:38 65 {*store} (nil)) (insn 812 245 230 14 (set (reg/f:DI 743) (reg/f:DI 1057)) t.f90:38 3335 {mymovdi} (expr_list:REG_EQUAL (symbol_ref:DI ("list.5265") [flags 0x2] &lt;var_decl 0x7fc2cfd62ed8 list&gt;) (nil))) (insn 230 812 249 14 (set (mem:DI (reg/v/f:DI 602 [ integer_node ]) [3 MEM[(struct node_type *)integer_node_19].next+0 S8 A64]) (reg/f:DI 603 [ node ])) t.f90:37 65 {*store} (nil)) (call_insn 249 230 250 14 (set (reg:DI 3678 $r4) (call (mem:DI (symbol_ref:DI ("malloc") [flags 0x41] &lt;function_decl 0x7fc2cfe76700 __builtin_malloc&gt;) [0 __builtin_malloc S8 A64]) (const_int 0 [0]))) t.f90:136 3156 {*_call_value} (expr_list:REG_EH_REGION (const_int 0 [0]) (nil)) (expr_list:REG_CC_SETTER (use (reg:DI 3678 $r4)) (nil))) That is the version that will fail. The code that is fine is: (code_label 218 213 219 14 21 "" [1 uses]) (note 219 218 220 14 [bb 14] NOTE_INSN_BASIC_BLOCK) (insn 220 219 248 14 (set (mem/f/c:DI (plus:DI (reg/f:DI 2134 IN2) (const_int -560 [0xfffffffffffffdd0])) [3 MEM[(struct __class_poly_list_Node_type_p *)&amp;node]+0 S8 A128]) (reg/f:DI 603 [ node ])) t.f90:37 65 {*store} (nil)) (insn 248 220 774 14 (set (reg:DI 3678 $r4) (const_int 24 [0x18])) t.f90:136 3181 {mymovdi} (nil)) (insn 774 248 245 14 (set (reg/f:DI 735) (reg/f:DI 1045)) t.f90:37 3335 {mymovdi} (expr_list:REG_EQUAL (symbol_ref:DI ("__poly_list_MOD___vtab_poly_list_Node_type") [flags 0x2] &lt;var_decl 0x7f25a3607720 __vtab_poly_list_Node_type&gt;) (nil))) (insn 245 774 224 14 (set (mem/c:DI (plus:DI (reg/f:DI 1057) (const_int 16 [0x10])) [3 list.tail+0 S8 A64]) (reg/f:DI 603 [ node ])) t.f90:38 65 {*store} (nil)) (insn 224 245 812 14 (set (mem/f/c:DI (plus:DI (reg/f:DI 2134 IN2) (const_int -552 [0xfffffffffffffdd8])) [3 MEM[(struct __class_poly_list_Node_type_p *)&amp;node + 8B]+0 S8 A64]) (reg/f:DI 1045)) t.f90:37 65 {*store} (nil)) (insn 812 224 231 14 (set (reg/f:DI 743) (reg/f:DI 1057)) t.f90:38 3335 {mymovdi} (expr_list:REG_EQUAL (symbol_ref:DI ("list.5265") [flags 0x2] &lt;var_decl 0x7f25a361bed8 list&gt;) (nil))) (insn 231 812 232 14 (set (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ]) (mem/c:DI (plus:DI (reg/f:DI 1053) (const_int 8 [0x8])) [12 MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 S8 A64])) t.f90:37 5 {*load} (expr_list:REG_DEAD (reg/f:DI 1053) (nil))) (insn 232 231 247 14 (set (mem:DI (plus:DI (reg/v/f:DI 602 [ integer_node ]) (const_int 8 [0x8])) [3 MEM[(struct node_type *)integer_node_19].next+8 S8 A64]) (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ])) t.f90:37 65 {*store} (expr_list:REG_DEAD (reg/v/f:DI 602 [ integer_node ]) (nil))) (insn 247 232 230 14 (set (mem/c:DI (plus:DI (reg/f:DI 1046) (const_int 8 [0x8])) [3 list.tail+8 S8 A64]) (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ])) t.f90:38 65 {*store} (expr_list:REG_DEAD (reg:DI 742 [ MEM[(struct __class_poly_list_Node_type &amp;)&amp;node]+8 ]) (nil))) (insn 230 247 249 14 (set (mem:DI (reg/v/f:DI 602 [ integer_node ]) [3 MEM[(struct node_type *)integer_node_19].next+0 S8 A64]) (reg/f:DI 603 [ node ])) t.f90:37 65 {*store} (nil)) (call_insn 249 230 250 14 (set (reg:DI 3678 $r4) (call (mem:DI (symbol_ref:DI ("malloc") [flags 0x41] &lt;function_decl 0x7f25a372f700 __builtin_malloc&gt;) [0 __builtin_malloc S8 A64]) (const_int 0 [0]))) t.f90:136 3156 {*_call_value} (expr_list:REG_EH_REGION (const_int 0 [0]) (nil)) (expr_list:REG_CC_SETTER (use (reg:DI 3678 $r4)) (nil))) </pre> Mike Stump 2013-05-10T19:56:44 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.fortran