http://permalink.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/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</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</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" } </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:5</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 [ i</pre> Mike Stump 2013-05-10T19:56:44 http://permalink.gmane.org/gmane.comp.gcc.fortran/40926 <pre>Hi, yes, actually I also thought that splitting it up might be a good idea. Right. However, the question is whether the patch will not become too involved for backporting. My weekend is extremely tight, but I might find a quite hour in the evenings during the next week (unless you can beat me to it) ... Cheers, Janus </pre> Janus Weil 2013-05-10T17:05:26 http://permalink.gmane.org/gmane.comp.gcc.fortran/40923 <pre> That's still unclear. The internal representation of arrays (array descriptor, dope vector) uses 3 bits to represent the rank, which allows for 2**3 = 8 values, which are used for rank == 0 (scalar) to rank == 7. Thus, supporting rank &gt; 7 arrays is not possible without incompatible changes. A new array descriptor is currently developed, but many aspects of the internal representation have to be changed, it will take a while. The internal representation of that array is documented in ISO/IEC Technical Specification (TS) 29113:2012, http://gcc.gnu.org/wiki/GFortranStandards#TS_29113_Further_Interoperability_of_Fortran_with_C My guess is that the new descriptor will either be used in GCC 4.9, which could be in two months. Or in GCC 4.10 if it will not ready in time. If you want to try it, you could build GCC/gfortran from the Fortran-Dev branch, which supports rank 15 arrays. There are still some issues, but most features should work. Tobias </pre> Tobias Burnus 2013-05-10T12:27:18 http://permalink.gmane.org/gmane.comp.gcc.fortran/40922 <pre>Dear gfortran developers, I would like to know when gfortran will suport a maximum rank of 15 for arrays. Best regards, Romeu. </pre> Romeu Braz Pereira Gomes Filho 2013-05-10T11:36:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.fortran