[Bug target/103476] --enable-maintainer-mode fails with "invalid separator" in libgfortran on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476 --- Comment #2 from tkoenig at netcologne dot de --- On 29.11.21 20:57, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476 > > --- Comment #1 from Andreas Schwab --- > 1202:$(srcdir)/generated/matmulavx128_c17.c; > OK, that's it. It also seems that I configured the wrong binary branch. Thanks for the help! Best regards Thomas
[Bug fortran/55591] strict-aliasing & Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #11 from tkoenig at netcologne dot de --- Am 05.04.19 um 18:20 schrieb dominiq at lps dot ens.fr: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 > > --- Comment #10 from Dominique d'Humieres --- >> Testing the updated patch > > The patch retested cleanly, but so far does not show a noticeable compilation > speed up (pr55585 being fixed since some time). > >> Ugh, this looks like a very bad idea. -fstrict-aliasing is very picky >> about type punning and, the last time I looked, the Fortran front-end >> wasn't particularly careful about it. Having a safe optimization mode >> wrt it is generally helpful. > > If there is no further feedback, I'll close the PR as WONTFIX. It might actually make more sense to set the default to "no" (if that isn't already happening by default, I haven't checked).
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #18 from tkoenig at netcologne dot de --- Am 02.04.19 um 20:48 schrieb anlauf at gcc dot gnu.org: > I had rejected procedure arguments to TRANSFER in my initial patch, see > > https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html > > but Thomas persuaded me to be less strict. I guess I had it wrong, then. Procedure pointer arguments to functions should be OK and take their type etc. information from the type of the pointer. Also, functions returning pointers should be permitted. This is what I orignally had in mind. I agree that mysel a subroutine argument or pure function argument makes no sense.
[Bug fortran/82018] [6/7/8 Regression] missing warnings with -Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82018 --- Comment #3 from tkoenig at netcologne dot de --- Am 29.08.2017 um 10:35 schrieb janus at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82018 > > --- Comment #2 from janus at gcc dot gnu.org --- > (In reply to janus from comment #0) >> >> i8 = 2.0 >> 1 >> Warning: Possible change of value in conversion from REAL(4) to INTEGER(8) >> at (1) [-Wconversion] > > Note that if I change 2.0 to 2.1 here, I do get a warning also with gfortran > 6. > It seems this was an intended change of behavior. > > However I would argue that the warning was useful indeed. In a well-written > code one should write "i8 = 2" instead of "i8 = 2.0". > > Maybe one could re-enable such warnings at least with -Wextra? The warning is given with -Wconversion-extra. We could enable -Wconversion-extra with -Wextra.
[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81298 --- Comment #8 from tkoenig at netcologne dot de --- Am 03.07.2017 um 23:40 schrieb ebotcazou at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81298 > > Eric Botcazou changed: > > What|Removed |Added > > CC||ebotcazou at gcc dot gnu.org > > --- Comment #7 from Eric Botcazou --- >> Why do we depend on exactly this version? *sigh* > > I think we don't want a minor change to configure.ac to result in a upheaval > in > the generated configure script. We have dozens of configure scripts and > dozens > of developers, this would be a mess if everyone was free to use his pet > version. I understand that desire, but autoconf 2.69 has been around since 2012. It is hardly a fast-moving target. I think it would be better to make a change towards 2.69. The fewer versions of extra software we have to use to compile gcc, the better.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #47 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2013-02-18 21:24:31 UTC --- Am 18.02.2013 21:16, schrieb jb at gcc dot gnu.org: Look at this piece of code: /* Seek to the head and overwrite the bogus length with the real length. */ if (unlikely (sseek (dtp-u.p.current_unit-s, - m - 2 * record_marker, SEEK_CUR) 0)) goto io_error; This works if it happens within a buffer, but you cannot rely on that. I would therefore suggest to resolve this PR by issuing a well-defined error if we encounter a pipe on opening. I'll prepare a patch. As I explained in comment #23, this is already handled. When opening a file, we stat() the fd, and use the buffered I/O functions only if it's a regular file, otherwise the unbuffered raw I/O functions are used. This is part of the precipitate, not part of the solution ;-) For unformatted sequential, we first write a dummy record marker, write the data and the final record marker, then seek to the first marker and re-write that. Of course, this fails for an unbuffered fifo. If we want this to work, we should make sure we always use _buffered_ I/O for unformatted sequential, setting a maximum record length on open that we can handle with our buffer.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #48 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2013-02-18 21:29:22 UTC --- Am 18.02.2013 20:15, schrieb dominiq at lps dot ens.fr: Are you suggesting to fix the non working named pipes on Darwin by removing them everywhere? Actually, the error happens everywhere, I could reproduce the error with unformatted sequential on my Linux box. If yes, isn't it a little bit too radical? Formatted sequential, unformatted stream and formatted stream would continue to work. As BACKSPACE most certainly will not work on a pipe, I don't see the advantage of using unformatted sequential.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #41 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2012-12-23 15:09:59 UTC --- Am 23.12.2012 15:16, schrieb dominiq at lps dot ens.fr: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #40 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-23 14:16:52 UTC --- Unfortunately, I cannot really debug this without access to a machine where it fails. Would it be possible to write a simple C test that can be run on the different platforms in order to check the behavior of lseek? The tests that you ran with the patchlet show that the error is not in setting errno on the lseek. It has to be somewhere else. If you still have the time, could you attach the truss output of program main open (10,file=pipe,status=old) write (10,'(A)') 'Hello, world!' end program main where pipe is a FIFO, and the same for program read character(len=100) c open (10,file=pipe, status=old) read (10,'(A)') c print *,trim(c) end program read (first starting read, then write).
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #35 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2012-12-22 15:38:08 UTC --- I still see status from open is0 status from open is0 At line 7 of file pr30162_1.f (unit = 20, file = 'np') Fortran runtime error: Illegal seek [1]Exit 2a.exe At line 8 of file pr30162_2.f (unit = 21, file = 'np') Fortran runtime error: I/O past end of record on unformatted file on x86_64-apple-darwin10 r194681. This is strange. Can you strace (or whatever) the code and tell me what lseek() returns? Is it really EINVAL like the error message suggests? If so, this would be strange, because http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/lseek.2.html tells me (as a return value) [EINVAL] Whence is not a proper value. [ESPIPE] Fildes is associated with a pipe, socket, or FIFO. which indicates a bug in the library, but maybe I am looking at the wrong manpage here.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #37 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2012-12-22 20:16:07 UTC --- Hi Dominique, The best I can do (without understanding it) is (1) if I use dtruss (should be equivalent to strace) on a, I get [macbook] f90/bug% 25210/0x2baef9e: lseek(0x3, 0x0, 0x1) = -1 Err#29 25210/0x2baef9e: lseek(0x3, 0xFFF4, 0x1) = -1 Err#29 (2) if I use it on b, I get [macbook] f90/bug% 25218/0x2baf031: lseek(0x3, 0x0, 0x1) = -1 Err#29 25218/0x2baf031: lseek(0x3, 0x4, 0x1) = -1 Err#29 That doesn't point to anything suspicious. Can you tell me what happens if you apply this patch? Index: io/unix.c === --- io/unix.c (Revision 194679) +++ io/unix.c (Arbeitskopie) @@ -349,7 +349,7 @@ /* Non-seekable files should always be assumed to be at current position. */ - if (x == -1 errno == ESPIPE) + if (x == -1) x = 0; return x;
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #4 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2012-09-30 20:24:03 UTC --- Am 30.09.2012 21:12, schrieb shart6 at utk dot edu: If n_elist = 1, then high = low = 0, and the funtion will always return 0, even if the unit passed in to search for is in the exception list. If there are n_elist exceptions, then they can be found in elist[0], ..., elist[n_elist-1]. If there is one exception, then it can be found at elist[0].
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #26 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-11-26 09:22:15 UTC --- Am 25.11.2011 18:44, schrieb burnus at gcc dot gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #25 from Tobias Burnusburnus at gcc dot gnu.org 2011-11-25 17:44:29 UTC --- (In reply to comment #24) Thanks for the bugreport and the (valid) testcase. To be pedantic, the test case was not valid Can you tell me what's wrong with the test case of comment 16? It looks perfectly valid to me. I'l defer to authority here :-) To quote Dick Hendrickson in the thread ttps://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6dfe2c3088f89725/3f69c230c86db253?hl=deie=UTF-8q=functions+*+side+effects+group:comp.lang.fortran+author:Thomas+author:Koenig#3f69c230c86db253 # In this case, I think the standard is clear. The processor is # allowed to evaluate f(3) once or twice. By the words # Richard quoted, a function is not allowed to affect or be # affected by anything else in the statement. So, one evaluation # of f(3) can't change the result of the other, and the processor # is free to evaluate f(3) + f(3) as 2*f(3). It # is processor dependent. Richard Maine sort of disagreed, he thinks the program is illegal. So, either way, optimizing away a function call would be OK.
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #24 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-11-25 17:24:19 UTC --- Am 24.11.2011 21:51, schrieb burnus at gcc dot gnu.org: Thanks for the bugreport and the (valid) testcase. To be pedantic, the test case was not valid; however, as a design choice, we chose to support it, because the error it had is very common.
[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #10 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-11-19 10:57:23 UTC --- Am 19.11.2011 11:18, schrieb anlauf at gmx dot de: This won't work. The implementation of the management of temporaries does not allow that the same instance is used more than once. If I understand your code, you are modifying the arguments of your function and evaluating that function more than once in a single expression. This is illegal in Fortran, so gfortran could, in principle, do anything with it. I would advise you to fix your code to be standard-conforming. Because such code is unfortunately quite common, gfortran by default does not do such optimizations unless directed to be. The fact that it does here nonetheless is, indeed, a bug.
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 --- Comment #1 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-10-11 18:03:56 UTC --- To me, the right strategy appears to be to mark the temporary variable as threadprivate if we are within an OMP block. Does this sound right?
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #9 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-10-10 18:57:09 UTC --- implicit none integer :: i real :: A(5), B(5) B(1) = 3.344 A = [real :: 1, 2, 3, 4, 5 ] !$omp parallel default(shared) !$omp workshare A(:) = A(:)*cos(B(1))+A(:)*cos(B(1)) !$omp end workshare nowait !$omp end parallel ! sync is implied here print *, A end Answer: With -O, one gets an ICE: The equivalent test case (inserting the BLOCK by hand) gets a very strange error, PR 50688 .
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #7 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-10-09 18:10:37 UTC --- Am 09.10.2011 18:14, schrieb burnus at gcc dot gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #6 from Tobias Burnusburnus at gcc dot gnu.org 2011-10-09 16:14:43 UTC --- (In reply to comment #5) one has a problem as tmp is shared. Thus, one needs to make sure that all inserted temporary variables are thread private (DECL_THREAD_LOCAL_P). Actually, it probably works as one declares tmp as BLOCK in the DO loop, which presumably generates a thread-private variable. Could you supply a complete test case? I'd like to check this out, but# I don't use OpenMP myself.
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #7 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-05-16 18:10:03 UTC --- Hi Paul, Indeed - I just need to find the time to sort out the logic. Structurally the patch is OK. I think the logic could be as follows: You could have two flags, one FORWARD_ALLOWED and one BACKWARD_ALLOWED. Initialize both flags to true. Run through all the references which could introduce a dependency. If there is a GFC_EQUAL dependency, do nothing. If there is a GFC_FORWARD dependency, set BACKWARD_ALLOW to false. If there is a GFC_BACKWARD dependency, set FORWARD_ALLOW to false. When selecting the loop direction: - If FORWARD_ALLOW is set, select a forward loop; else If BACKWARD_ALLOW is set, select a forward loop; else mark this dimension as needing a temporary. Does this sound OK? Thomas
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 --- Comment #9 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-02-21 22:40:52 UTC --- Hi Paul, (In reply to comment #7) Any plan to backport the fix in revision 170317? I had not planned so to do but would respond positively to popular pressure how far back would you want to go? I think 4.5 would be great. Anything further back is probably unneeded (the bug has remained undetected for a few years now...) Thomas
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #25 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-01-16 16:23:29 UTC --- Maybe it would be better to set the inherited pointer and target attributes much earlier, in gfc_variable_attr. With a bit of luck, things would then work automatically.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #17 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-01-09 16:00:14 UTC --- Am 09.01.2011 16:33, schrieb burnus at gcc dot gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-09 15:33:02 UTC --- (In reply to comment #13) The test case from comment 6 gives an ICE (segfault) in gfc_conv_procedure_call's check for fsym-as-type != AS_ASSUMED_SHAPE; (guess: fsym-as is NULL) Actually, it's in conv_isocbinding_procedure (which got inlined). The issue seems to be that the code assumes that arg-expr-rank != 0 implies that arg-expr-symtree-n.sym-as is set. However, the assumption fails for: p = c_loc(tt%t%i(1)) as tt is a scalar. I'm looking at this.
[Bug fortran/45159] Unnecessary temporaries
--- Comment #18 from tkoenig at netcologne dot de 2010-08-10 09:19 ---
Subject: Re: Unnecessary temporaries
Am Dienstag, den 10.08.2010, 08:45 + schrieb dominiq at lps dot ens
dot fr:
I think that
+ identical_strides = gfc_dep_compare_expr (l_stride, r_stride)
== 1;
should also be replaced with
+ identical_strides = gfc_dep_compare_expr (l_stride, r_stride)
== 0;
Correct.
Although it is probably better set the stride during resolution.
Here's a tentative patch for that. There are probably very many places
that NULL checks can be elided with this.
Index: resolve.c
===
--- resolve.c (Revision 163041)
+++ resolve.c (Arbeitskopie)
@@ -4378,12 +4378,19 @@
return FAILURE;
}
+ /* Always fill in a stride of one. */
+
+ if (ar-dimen_type[i] == DIMEN_RANGE
+ ar-stride[i] == NULL)
+ ar-stride[i] = gfc_get_int_expr (gfc_index_integer_kind,
+ ar-where, 1);
+
/* Fill in the upper bound, which may be lower than the
specified one for something like a(2:10:5), which is
identical to a(2:7:5). Only relevant for strides not equal
to one. */
if (ar-dimen_type[i] == DIMEN_RANGE
- ar-stride[i] != NULL ar-stride[i]-expr_type ==
EXPR_CONSTANT
+ ar-stride[i]-expr_type == EXPR_CONSTANT
mpz_cmp_si (ar-stride[i]-value.integer, 1L) != 0)
{
mpz_t size, end;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #13 from tkoenig at netcologne dot de 2010-07-08 19:55 --- Subject: Re: [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70% Hello Paul, That is the context - apply it and see. What about module baz implicit none contains subroutine bar(x) real, dimension(:,:,:) :: x x = 3.0 end subroutine bar end module baz program sw use baz implicit none integer, parameter :: n = 4, m = 7, k = 5 real ,dimension(M,N):: f,dudx,dvdy,dhdx,dhdy real, dimension(m,n,k) :: u u = 1.0 dudx = ddx(u(:,:,2)) print *,dudx contains real function ddx(array) real, dimension(:,:) :: array call bar(u) ddx = array(1,1) end function ddx end program sw AFAICS, this is legal and would require a temporary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug fortran/37131] inline matmul for small matrix sizes
--- Comment #13 from tkoenig at netcologne dot de 2010-06-05 18:27 --- Subject: Re: inline matmul for small matrix sizes mikael at gcc dot gnu dot org wrote: I'm working on nested scalarization loops for the sum intrinsic (pr43829) ; inlining matmul should be straightforward after that. I agree that this is the best approach - teach the scalarizer about multidimensional arrays. I'll hold further work on this PR until your work in this is finished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #2 from tkoenig at netcologne dot de 2010-05-16 19:03 --- Subject: Re: dot_product / matmul and signed zeros kargl at gcc dot gnu dot org wrote: The generated code is fine. The F2003 standard states on page 38. The real type includes a zero value. Processors that distinguish between positive and negative zeros shall treat them as equivalent (1) in all relational operations, (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished, and MATMAL and DOT_PRODUCT are not in the list that (2) applies to. In this case, the negative zero is the _result_; it is not passed as an argument (what's being passed are 0.0 and -1.0, respectively). So, this looks like a question for c.l.f. And yes, there are bugs that are more severe than this ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/36934] [4.4 regression] Spurious ambiguous reference to...ERROR/ICE
--- Comment #7 from tkoenig at netcologne dot de 2008-07-25 21:58 --- Subject: Re: [4.4 regression] Spurious ambiguous reference to...ERROR/ICE On Fri, 2008-07-25 at 21:44 +, burnus at gcc dot gnu dot org wrote: I think it was my mistake. I assume Philip used my x86-64-linux nightly build. I found out that I applied Daniel's finalizer patch to the wrong tree. So, resolve this as fixed and add a test case? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36934
[Bug testsuite/35939] maxloc_bounds_[457].f90 fail with -fdefault-integer-8
--- Comment #2 from tkoenig at netcologne dot de 2008-05-16 15:27 --- Subject: Re: maxloc_bounds_[457].f90 fail with -fdefault-integer-8 On Thu, 2008-05-15 at 21:48 +, janis at gcc dot gnu dot org wrote: --- Comment #1 from janis at gcc dot gnu dot org 2008-05-15 21:48 --- Thomas, does the suggested change to the tests make sense, or would it be better to skip these tests if they would be run using -fdefault-integer-8? Fix the test case; this change is pre-approved. It would be (slightly) preferable if the test case didn't contain any kind=4 or kind=8 specification. I wrote them, but I can't remember why I put the kind=xxx in there. For the failures with C interop, it would still be interesting to have a method of excluding the tests if we decide to run the testsuite during normal testing with -fdefault-integer-8. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35939
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #9 from tkoenig at netcologne dot de 2008-05-04 10:15 --- Subject: Re: run-time abort for PACK of run-time zero sized array On Sun, 2008-05-04 at 09:59 +, dominiq at lps dot ens dot fr wrote: --- Comment #7 from dominiq at lps dot ens dot fr 2008-05-04 09:59 --- If I am not mistaken, the patch for libgfortran/intrinsics/pack_generic.c has not been commited yet. Thanks a lot, Dominique! I just committed that part. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #2 from tkoenig at netcologne dot de 2008-01-05 11:48 --- Subject: Re: bounds checking for array intrinsics Hi Jerry, Do we want the overhead of bounds checking at run time on all these intrinsics? In the case of no bounds checking, it's a single if statement. Is there a way to do it without the overhead? We could duplicate every intrinsic array function, one version with bounds checking and one without, then call the appropriate function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug libfortran/32972] performance of pack/unpack
--- Comment #10 from tkoenig at netcologne dot de 2007-12-09 10:33 --- Subject: Re: performance of pack/unpack On Sat, 2007-12-08 at 21:57 +, jvdelisle at verizon dot net wrote: --- Comment #9 from jvdelisle at verizon dot net 2007-12-08 21:57 --- Subject: Re: performance of pack/unpack tkoenig at gcc dot gnu dot org wrote: we could make specific versions of all those intrinsic that currently use memcpy(), including pack. Should we leave this bug open for this? Yes. Is this related to the following: http://gcc.gnu.org/ml/fortran/2007-12/msg00051.html ? Yes, this would take care of it for the intrinsic types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libfortran/34328] access=stream,form=formatted doesn't buffer
--- Comment #3 from tkoenig at netcologne dot de 2007-12-04 07:03 --- Subject: Re: access=stream,form=formatted doesn't buffer On Tue, 2007-12-04 at 02:36 +, jvdelisle at gcc dot gnu dot org wrote: $ strace -e write,read,_llseek ./a.out read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\4\1\0\0\0\0\0..., 832) = 832 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0`\240\f7\0\0\0..., 832) = 832 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\340\'\0\0\0\0\0\0..., 832) = 832 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320\333a\f7\0\0\0..., 832) = 832 write(3, a\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\n..., 200) = 200 This is with current trunk. I got rid of the extra flush when I committed the last patch. I tested it after it was mentioned on IRC. (see PR33985) Thomas, you spotted it. Yes, I now get the same result (after correctly upgrading). Thanks Jerry! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34328
[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90
--- Comment #15 from tkoenig at netcologne dot de 2007-11-03 20:19 --- Subject: Re: FAIL: gfortran.dg/gamma_5.f90 --- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03 19:37 --- Now, the hard part. The gfortran.dg/gamma_5.f90 test fails at n = 16. This works on my i686-pc-linux-gnu system, and also fails when I use -ffloat-store. Seems like we have a roundoff problem with normal ieee double precision. I'll continue to work on it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
