[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-11 06:25 --- Subject: Bug 31823 Author: brooks Date: Wed Jul 11 06:25:47 2007 New Revision: 126538 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126538 Log: Backport from trunk: PR fortran/31823 * intrinsic.texi (CMPLX): Document result kind. (COMPLEX): Add documentation. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-11 06:34 --- Fixed, as per the above commit. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-03 19:45 --- Nick - So, if I understand correctly: all of the options are listed somewhere, but we no longer provide any information about which of the shared options under language related options are supported by a given language's front end? While this may have been intentional, I do not think it counts as a feature -- the listing of the common options without definitions at the top of the option listing did not take up a significant amount of space, and it provided very useful information that's now not absent. (On the other hand, moving the _descriptions_ of the shared options to a single listing is a good thing, IMO -- I want to make it clear that I'm not objecting to the bulk of this change!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-03 19:46 --- Er, that's now absent, I mean. An extraneous not crept into the second paragraph of my last comment when I was editing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug fortran/32137] New: [4.3 regression] func_result_3.f90 ICEs on powerpc-apple
From the gfortran testsuite log: Executing on host: /Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../gfortran -B/Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../ /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90 -O -pedantic-errors -S -o func_result_3.s(timeout = 300) /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90: In function 'quadric': /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90:8: internal compiler error: in gfc_trans_dummy_array_bias, at fortran/trans-array.c:4046 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90: In function 'quadric': /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90:8: internal compiler error: in gfc_trans_dummy_array_bias, at fortran/trans-array.c:4046 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gfortran.dg/func_result_3.f90 -O (internal compiler error) FAIL: gfortran.dg/func_result_3.f90 -O (test for errors, line 18) FAIL: gfortran.dg/func_result_3.f90 -O (test for excess errors) -- Summary: [4.3 regression] func_result_3.f90 ICEs on powerpc-apple 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: brooks at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.9.0 GCC host triplet: powerpc-apple-darwin8.9.0 GCC target triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32137] [4.3 regression] func_result_3.f90 ICEs on powerpc-apple
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-29 07:27 --- I should have noted: I think this showed up within the last week, but I can confirm that it's not in my saved testsuite results from 2007-05-07. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-29 07:35 --- Update: This isn't a regression; the testcase is new. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression]|[4.3] func_result_3.f90 ICEs |func_result_3.f90 ICEs on |on powerpc-apple |powerpc-apple | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #5 from brooks at gcc dot gnu dot org 2007-05-29 18:45 --- As of SVN 125160, this is working again. Weird, indeed. I guess I'll close it as a chimera. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 --- Subject: Bug 31972 Author: brooks Date: Mon May 28 20:53:09 2007 New Revision: 125141 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125141 Log: PR 31972/fortran * target-memory.c (gfc_target_expr_size): Add handling for size of BT_HOLLERITH variables. * check.c (gfc_check_transfer): Reject BT_HOLLERITH variables in MOLD argument of TRANSFER. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/target-memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 --- Subject: Bug 31972 Author: brooks Date: Mon May 28 20:54:49 2007 New Revision: 125142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125142 Log: PR fortran/31972 * transfer_hollerith_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_hollerith_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 --- Fixed, as per above commits. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 --- Paul, I don't think that's solving the right problem. The code is legal; the inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which conforms with a CHARACTER scalar of len=20. In reducing this, I discovered that gfortran currently hangs on the following much simpler code. I suspect that if we fix this, it'll fix the original code too. write(*,*) transfer(A, x, 20) end -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-18 07:03:32 |2007-05-28 21:09:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #4 from brooks at gcc dot gnu dot org 2007-05-29 05:59 --- I misunderstood something slightly in that last comment; MERGE is elemental, so the conforming I mentioned doesn't matter. Also, my guess that fixing the transfer(A, x, 20) problem would fix the whole thing proved to be incorrect. So, even once the first bit is fixed, if we change the code to be legitimate, as follows, then it still has an error: character(len=20) :: string logical :: a(20) write(*,*) transfer (merge (transfer(A, x, 20), b, a), string ) end Specifically, we ICE by failing the gcc_assert (integer_zerop (loop - from[n])) at line 593 of trans-array.c, when doing gfc_conv... stuff to the arguments of the outer transfer function. I'm having a bear of a time tracking down why this is happening. The problem is that we're generating a temporary, so loop-temp_dim is 1 (as set in gfc_trans_constant_array_constructor, line 1576). However, the loop seems to be picking up dimensions from the result of the inner transfer function somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR, a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the info-start[0] and info-end[0] values to be set (to 1 and 20, respectively) in gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values for the loop. I can't seem to duplicate this with any other set of functions. It's only happening with characters, not integers, and if I break up the expression or substitute other things for transfer and merge, it doesn't replicate this behavior. Help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-17 22:45 --- Yeah, this is to be expected, I think. Holleriths store the memory representation but not the semantic representation of their value, and transfer tries to fold things and gets confused. There's probably an easy fix for this, or there's also the fact that when the transfer implementation is updated to do proper in-memory stuff (to account for things like TRANSFER(TRANSFER(34, .TRUE.), 0) which should return 34), fixing this will fall out of it if done right. I'm accepting this because I plan to do the latter in a way that will fix this as a side effect. However, if someone cares, I can also put in a code to do this appropriately in the short term as well. -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-17 17:33:59 |2007-05-17 22:45:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31823] New: [4.2 regression] COMPLEX not documented
The COMPLEX intrinsic is not documented in 4.2. -- Summary: [4.2 regression] COMPLEX not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-04 22:11 --- Created an attachment (id=13510) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13510action=view) Documentation patch for COMPLEX -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-05 00:29 --- Created an attachment (id=13512) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13512action=view) Documentation patch (not corrupted, this time) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Attachment #13510|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-03 07:15 --- Subject: Bug 31776 Author: brooks Date: Thu May 3 06:14:52 2007 New Revision: 124373 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124373 Log: PR bootstrap/31776 * system.h: Remove inclusion of double-int.h * tree.h: Include double-int.h * gengtype.c: Likewise * cfgloop.h: Likewise * Makefile.in: Adjust dependencies on double-int.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cfgloop.h trunk/gcc/gengtype.c trunk/gcc/system.h trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-03 07:22 --- The above commit should fix this problem. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #5 from brooks at gcc dot gnu dot org 2007-05-03 03:24 --- If this analysis of the problem is correct, the patch attached here should fix it: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00135.html -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-03 02:50:22 |2007-05-03 03:24:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #8 from brooks at gcc dot gnu dot org 2007-04-23 20:48 --- *** Bug 31672 has been marked as a duplicate of this bug. *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/31672] Not Implemented: Initialization of overlapping variables
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-23 20:48 --- Thanks for reporting this -- this is a rather nicer testcase than the one we had for this already. I've also changed the title of PR #29786 to make it easier to find. *** This bug has been marked as a duplicate of 29786 *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31672
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
--- Comment #9 from brooks at gcc dot gnu dot org 2007-04-23 20:49 --- I'm changing the name of this bug to make it a lot easier to find, now that we know what the actual problem is. Also, PR #31672 contains an excellent testcase for this, which I'll quote here: -- function d1mach(i) implicit none double precision d1mach,dmach(5) integer i,large(4),small(4) equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) data small(1),small(2) / 0, 1048576/ data large(1),large(2) /-1,2146435071/ d1mach = 0.0d0 end function d1mach -- -- brooks at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression] |rejects equivalence |Initialization of ||overlapping variables: Not ||implemented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
-- brooks at gcc dot gnu dot org changed: What|Removed |Added Priority|P5 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-20 01:52 --- This is invalid code, since initialization expressions must be constants, and the length of an assumed-length string argument is not a constant. Regardless, we shouldn't be ICE'ing on it. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-04-20 01:52:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected
-- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-03 12:36:28 |2007-04-06 22:56:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30881
[Bug fortran/31216] TRANSFER in CASE leads to ICE
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 19:50:30 |2007-04-06 22:58:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31216
[Bug fortran/31194] NaN transfer - internal compiler error: in gfc_conv_constant
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 20:24:20 |2007-04-06 23:00:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31194
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #2 from brooks at gcc dot gnu dot org 2007-04-06 23:06 --- The following code repeats the ICE: character(LEN=2), parameter :: a=a real, dimension(2,2), parameter :: r=1.0 character(LEN=4) :: b=REPEAT(a,2) real, dimension(4) :: l=RESHAPE(r,(/4/)) character(LEN=3) :: c=TRIM(a ) IF (b.NE.a a ) CALL ABORT() IF (ANY(l.NE.1.0)) CALL ABORT() IF (c.NE.a ) CALL ABORT() END This is thus not something coming from the lack of transfer constant-folding. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org OtherBugsDependingO|31237 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-03 17:54:10 |2007-04-06 23:11:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #2 from brooks at gcc dot gnu dot org 2007-04-06 23:12 --- This looks related to 31218, so I'm adding a dependency even though I'm not certain it's the same. Also confirming, because it's definitely a bug even if it's a duplicate one. -- brooks at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31218 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 23:12:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug driver/31353] gcc --help=target gives a linker error.
--- Comment #5 from brooks at gcc dot gnu dot org 2007-04-04 19:10 --- Subject: Bug 31353 Author: brooks Date: Wed Apr 4 19:10:17 2007 New Revision: 123498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123498 Log: PR other/31353 * gcc.c (main): Do not run the linker if print_subprocess_help indicates that it shouldn't be run. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31356] gcc --help=language option has problems in the output header line.
--- Comment #3 from brooks at gcc dot gnu dot org 2007-04-04 19:17 --- Subject: Bug 31356 Author: brooks Date: Wed Apr 4 19:17:30 2007 New Revision: 123499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123499 Log: PR other/31356 * gcc.c (print_specific_help): Fix --help=language header line. (common_handle_option): Support --help=common. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug driver/31353] gcc --help=target gives a linker error.
--- Comment #6 from brooks at gcc dot gnu dot org 2007-04-04 19:24 --- Fixed, as per the above commit. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31356] gcc --help=language option has problems in the output header line.
--- Comment #4 from brooks at gcc dot gnu dot org 2007-04-04 19:24 --- Fixed, as per the above commit. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug driver/31355] --help=language option isn't documented.
--- Comment #5 from brooks at gcc dot gnu dot org 2007-04-04 19:32 --- Fixed in svn 123497: (http://gcc.gnu.org/viewcvs?root=gccview=revrev=123497) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug driver/31355] --help=language option isn't documented.
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-28 19:22 ---
The patch tracker missed the patch I'd already posted for this one as well:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01655.html
I think our fixes are fairly equivalent here; yours specifies the list of
language, whereas mine uses @var{language} -- which I think is slightly better,
because the list of languages isn't necessarily fixed (and you missed obj-c++),
though I could see yours as being slightly clearer. However, note that my
patch includes some formatting fixes to this section, which should be
incorporated regardless.
(Note, by the way, that the small problem you mention in --help=language
output is Bug #31356. :) )
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-03-25 23:34:27 |2007-03-28 19:22:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug other/31356] gcc --help=language option has problems in the output header line.
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-28 19:23 --- Patch posted, but the patch tracker didn't see it: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01657.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug driver/31353] gcc --help=target gives a linker error.
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-28 19:17 --- I had previously posted a patch to fix this, as well, but apparently the patch tracker didn't pick up on it to attach it to the PR: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01658.html As mentioned on the patches list, I don't think that passing --help along to the subprocesses is the right thing to do here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31349] New: gcc -v --help returns no options for C, C++
To quote from the output of gcc -v --help on gcc (GCC) 4.3.0 20070323 (experimental): -- The following options are specific to the language Ada: -gnatoptions Specify options to GNAT The following options are specific to the language C: No options with the desired characteristics were found The following options are specific to the language C++: No options with the desired characteristics were found -- As can be seen by comparing this to the output from 4.2, something seems to be missing. (What's missing from Ada is all the options shared with C, specifically.) Similarly, on the Fortran output, while the Fortran-specific options are present, the ones shared with C and C++ aren't listed. 4.3 currently gives -- The following options are specific to the language Fortran: -Jdirectory Put MODULE files in 'directory' -Waliasing Warn about possible aliasing of dummy arguments [...] -- However, 4.2 gives: -- The Fortran front end recognizes the following options: -I, -Wall, -Wconversion, -fopenmp, -fpreprocessed, -fshort-enums -Jdirectory Put MODULE files in 'directory' -Waliasing Warn about possible aliasing of dummy arguments [...] -- The same problem with the missing shared options in the output occurs for other languages as well. -- Summary: gcc -v --help returns no options for C, C++ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug other/31350] New: gcc -v --help puts some output on std. out, and some on std. error.
gcc -v --help is inconsistent about where it places its output. If I try to redirect the output to a file (which is rather a reasonable thing to do, given how long it is!), some of it still gets printed to the console via standard error: bin-4.2/bin/gcc -v --help /dev/null Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion Thread model: posix gcc version 4.2.0 20070305 (prerelease) /home/brooks/bin-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -mtune=generic -auxbase help-dummy -version --help -o /tmp/cccRY7zh.s as -V -Qy --help -o /tmp/ccQzyIru.o /tmp/cccRY7zh.s GNU assembler version 2.15 (i386-linux) using BFD version 2.15 /home/brooks/bin-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 --help /usr/lib/crt1.o /usr/lib/crti.o /home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o -L/home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0 -L/home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/../../.. /tmp/ccQzyIru.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/crtend.o /usr/lib/crtn.o FWIW, this error only seems to be present with the gcc -v --help output; the regular gcc --help output all goes into the file, as expected. -- Summary: gcc -v --help puts some output on std. out, and some on std. error. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31350
[Bug other/31351] New: gcc -v --help has poor documentation for some shared Ada/C options
When an option is shared between multiple front ends, the output of gcc -v --help uses the documentation string from the first front end for which it is listed. Ada is listed before C, and thus all of the shared Ada/C options use the Ada documentation, rather than the C documentation. Unfortunately, the Ada lang.opt file doesn't have good documentation for some of these: --- The Ada front end recognizes the following options: -I This switch lacks documentation -Wall This switch lacks documentation -Wlong-long Do not warn about using long long when -pedantic -Wmissing-format-attribute Warn about functions which might be candidates for format attributes -Wmissing-prototypesWarn about global functions without prototypes -Wold-style-definition Warn if an old-style parameter definition is used -Wstrict-prototypes Warn about unprototyped function declarations -Wvariadic-macros Do not warn about using variadic macros when -pedantic -Wwrite-strings In C++, nonzero means warn about deprecated conversion from string literals to `char *'. In C, similar warning, except that the conversion is of course not deprecated by the ISO C standard. -fRTS= This switch lacks documentation -gnatoptions Specify options to GNAT -gnatO This switch lacks documentation -nostdinc Do not search standard system include directories (those specified with -isystem will still be used) -nostdlib This switch lacks documentation --- My personal opinion is that this would really be best fixed by listing C and C++ first in the --help output, since they're much more commonly used. However, a workaround would be copying the C documentation to the Ada lang.opt file. -- Summary: gcc -v --help has poor documentation for some shared Ada/C options Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31351
[Bug other/31352] New: gcc -v --help doesn't notice when front-ends documentation differs for same option
When an option is present in multiple front ends, the gcc -v --help output assumes that the documentation is the same in all of the front ends for which the option is present, and only reports the documentation string for the first front end for which it appears. For example, in 4.2, the Ada output has --- -Wall This switch lacks documentation --- and then, in the C output, we have --- -I, -Wall, -Wlong-long, -Wmissing-format-attribute, -Wmissing-prototypes, --- rather than giving the documentation string for -Wall that's present in c.opt. Currently, I _think_ this is only affecting the Ada options that lack documentation (and are thus bug #31351), but it seems unfortunate for the future as well, since some options may have different interpretations in different langauges. -- Summary: gcc -v --help doesn't notice when front-ends documentation differs for same option Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31352
[Bug other/31353] New: gcc --help=target gives a linker error.
Consider the following output: ~/bin-trunk/bin/gcc --help=target The following options are target specific: -m128bit-long-doublesizeof(long double) is 16 -m32Generate 32bit i386 code [...] -muclibcUse uClibc instead of GNU libc /usr/lib/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' collect2: ld returned 1 exit status This happens with any --help= option. It looks like the --help= option isn't turning off the parts of the compiler that do compilation, and so it's still trying to link an empty program. -- Summary: gcc --help=target gives a linker error. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31355] New: --help=language option isn't documented.
The documentation in invoke.texi for the --help= option only lists the optimizers, warnings, target, and params values that the option can take. However, it can also take a language name as a value, and this isn't documented. -- Summary: --help=language option isn't documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug other/31356] New: gcc --help=language option has problems in the output header line.
Consider the following output: ~/bin-trunk/bin/gcc --help=fortran The following options are supported by, amoung others, the language : -I This switch lacks documentation [...] The language name seems to be missing from the first line. (Also, amoung is an obvious typo.) -- Summary: gcc --help=language option has problems in the output header line. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug other/31357] New: --help and --help=value options cannot be combined.
As documented, using multiple --help=value options in one command line produces an output that concatenates the output from the various --help=value options. However, using both --help and --help=value gives only the --help output, regardless of the order in which they are specified. -- Summary: --help and --help=value options cannot be combined. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31357
[Bug driver/31353] gcc --help=target gives a linker error.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-25 23:33:06 |2007-03-26 00:21:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31356] gcc --help=language option has problems in the output header line.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-26 00:33:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug fortran/30875] Equivalence of derived types with (same) default initializer
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-17 23:39 --- At the end of 14.6.3.3, Default initialization may be specified for a storage unit that is storage associated provided the objects or subobjects supplying the default initialization are of the same type and type parameters, and supply the same value for the storage unit. It is somewhat unclear to me from that language whether the relevant constraint is that A1 and A2 would have to have the same type and type parameters (which they do not, making the code illegal), or whether A1%I and A2%I would have to have the same type and type parameters (which they do, making the code legal). I tried to get some further opinions about this on comp.lang.fortran, but apparently nobody found my question interesting enough to reply to. :) I've now found that MRC describes this condition as being that the components in question must have the same type and type parameters, which would make this legal, and I suspect that's the final answer we'll get. Thus, I'm confirming the bug; I can certainly reproduce the error message. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 23:39:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30875
[Bug fortran/31229] New: kind parameter in function declaration fails to find use-associated parameters
Bil Kleb posted the following code on comp.lang.fortran on 2007/3/16; Richard Maine agreed that it is valid but pointed out that it's a consistent weak spot in many compilers. I tested it on GFortran, and it does indeed fail here. debian-gfortran:~/test more kleb1.f90 module kinds integer, parameter :: dp = selected_real_kind(15) end module kinds module test_undeclared_kind; contains REAL(DP) function declared_dp_before_defined() use kinds, only: dp declared_dp_before_defined = 1.0_dp end function end module debian-gfortran:~/test ~/bin-trunk/bin/gfortran kleb1.f90 kleb1.f90:6.9: REAL(DP) function declared_dp_before_defined() 1 Error: Parameter 'dp' at (1) has not been declared or is a variable, which does not reduce to a constant expression [...] debian-gfortran:~/test ~/bin-trunk/bin/gfortran --version GNU Fortran (GCC) 4.3.0 20070316 (experimental) -- Summary: kind parameter in function declaration fails to find use-associated parameters Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
[Bug fortran/31234] New: Thread-safety of random_number should be documented.
As noted in this message: http://gcc.gnu.org/ml/fortran/2007-03/msg00339.html This should probably be documented in the manual. -- Summary: Thread-safety of random_number should be documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug fortran/31154] IMPORT fails for imported symbol FUNCTION (...) kind of procedures
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-16 22:39 --- This is probably related to Bug #31229. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
[Bug fortran/31229] kind parameter in function declaration fails to find use-associated parameters
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-16 22:40 --- This is probably related to Bug #31154 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
[Bug fortran/31193] New: ICE on count(transfer(...)...), with non-constant transfer arguments.
There are known problems with attempts at folding TRANSFER in constant expressions. However, the following code doesn't involve this, and should work properly even if folding of TRANSFER simply bails out without attempting to fold anything. Instead, it gives an ICE (in the middle-end, not in the Fortran front-end). debian-gfortran:~/test more awgrey2.f90 function NumOccurances(string,chr) result(n) character(*),intent(in) :: string character(1),intent(in) :: chr ! ! return number of occurances of character in given string ! n=count(transfer(string,char(1),len(string))==chr) return end debian-gfortran:~/test ~/bin-trunk/bin/gfortran awgrey2.f90 awgrey2.f90: In function 'numoccurances': awgrey2.f90:1: internal compiler error: in fold_binary, at fold-const.c:8999 Please submit a full bug report, debian-gfortran:~/test ~/bin-trunk/bin/gfortran --version GNU Fortran (GCC) 4.3.0 20070307 (experimental) -- Summary: ICE on count(transfer(...)...), with non-constant transfer arguments. 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: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #5 from brooks at gcc dot gnu dot org 2007-03-13 08:11 --- I believe that all of the nonstandard intrinsics have now been documented in 4.2 and 4.3, and thus I am closing this bug as fixed. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-13 08:47 --- This bug was erroneously closed. The following intrinsics are undocumented in 4.2: INT2, SHORT INT8, LONG MCLOCK MCLOCK8 SECOND The relevant bits of intrinsic.c: add_sym_1 (int2, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_int2, gfc_resolve_int2, a, BT_REAL, dr, REQUIRED); make_alias (short, GFC_STD_GNU); make_generic (int2, GFC_ISYM_INT2, GFC_STD_GNU); add_sym_1 (int8, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_int8, gfc_resolve_int8, a, BT_REAL, dr, REQUIRED); make_generic (int8, GFC_ISYM_INT8, GFC_STD_GNU); add_sym_1 (long, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_long, gfc_resolve_long, a, BT_REAL, dr, REQUIRED); make_generic (long, GFC_ISYM_LONG, GFC_STD_GNU); add_sym_0 (mclock, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, NULL, NULL, gfc_resolve_mclock); make_generic (mclock, GFC_ISYM_MCLOCK, GFC_STD_GNU); add_sym_0 (mclock8, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, NULL, NULL, gfc_resolve_mclock8); make_generic (mclock8, GFC_ISYM_MCLOCK8, GFC_STD_GNU); add_sym_0 (second, NOT_ELEMENTAL, ACTUAL_NO, BT_REAL, 4, GFC_STD_GNU, NULL, NULL, NULL); make_generic (second, GFC_ISYM_SECOND, GFC_STD_GNU); -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2006-06-16 23:51:33 |2007-03-13 08:48:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-13 09:00 ---
Relevant pieces of trans-intrinsic.c:
/* Integer conversions are handled separately to make sure we get the
correct rounding mode. */
case GFC_ISYM_INT:
case GFC_ISYM_INT2:
case GFC_ISYM_INT8:
case GFC_ISYM_LONG:
gfc_conv_intrinsic_int (se, expr, FIX_TRUNC_EXPR);
break;
case GFC_ISYM_MCLOCK:
case GFC_ISYM_MCLOCK8:
case GFC_ISYM_SECOND:
gfc_conv_intrinsic_funcall (se, expr);
break;
Relevant bits of iresolve.c:
void
gfc_resolve_int2 (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 2;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_int8 (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 8;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_long (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 4;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_mclock (gfc_expr * f)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 4;
f-value.function.name = PREFIX(mclock);
}
void
gfc_resolve_mclock8 (gfc_expr * f)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 8;
f-value.function.name = PREFIX(mclock8);
}
/* G77 compatibility subroutine second(). */
void
gfc_resolve_second_sub (gfc_code * c)
{
const char *name;
name = gfc_get_string (PREFIX(second_sub));
c-resolved_sym = gfc_get_intrinsic_sub_symbol (name);
}
Relevant part of intrinsics/cpu_time.c:
void
second_sub (GFC_REAL_4 *s)
{
cpu_time_4 (s);
}
extern GFC_REAL_4 second (void);
export_proto(second);
GFC_REAL_4
second (void)
{
GFC_REAL_4 s;
cpu_time_4 (s);
return s;
}
Note that cpu_time_4 is the kind=4 variant of CPU_TIME.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
CC||brooks at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/31160] New: %VAL and related features need to be documented.
As in the subject line; this feature was added (thanks, Paul!) but the documentation is still pending. -- Summary: %VAL and related features need to be documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31160
[Bug fortran/30953] intrinsic: CTIME
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-03 10:24:56 |2007-03-13 09:09:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #8 from brooks at gcc dot gnu dot org 2007-03-13 09:15 ---
Relevant parts of libgfortran/clock.c:
GFC_INTEGER_4
mclock (void)
{
#ifdef HAVE_CLOCK
return (GFC_INTEGER_4) clock ();
#else
return (GFC_INTEGER_4) -1;
#endif
}
GFC_INTEGER_8
mclock8 (void)
{
#ifdef HAVE_CLOCK
return (GFC_INTEGER_8) clock ();
#else
return (GFC_INTEGER_8) -1;
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #9 from brooks at gcc dot gnu dot org 2007-03-14 02:43 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:43:27 2007 New Revision: 122902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122902 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct REAL to REAL(*). (EXP): Add index entry for CEXP. (INT): Correct argument name to A. (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #10 from brooks at gcc dot gnu dot org 2007-03-14 02:45 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:45:14 2007 New Revision: 122903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122903 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct REAL to REAL(*). (EXP): Add index entry for CEXP. (INT): Correct argument name to A. (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-14 02:46 --- _Now_ this is fixed on 4.2 and trunk. :) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-14 04:19 --- Furthermore, the function form of CHDIR erroneously has A as the argument name. (Actually, all three of the names involved for this artgument are erroneous compared to the G77 documentation, which gives the variable name as DIR!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30953] intrinsic: CTIME
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30953 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #4 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30953] intrinsic: CTIME
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30953 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30953] intrinsic: CTIME
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-14 04:40 --- Fixed by the above commits on 4.2 and trunk. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #5 from brooks at gcc dot gnu dot org 2007-03-14 04:43 --- The above commits fix the erroneous argument name in the documentation; it is now documented to be NAME. In addition, the STATUS argument is now documented to only allow default integers (which can be int_4 or int_8 depending on the -fdefault-integer-kind argument). If the decision is made to call this variable PATH instead, the documentation will now need to be changed to match. The argument name for the function version is still A; this needs to be fixed. I'm removing the documentation keyword to reflect that the documentation is corrected, but leaving this open because of the other parts that are not yet fixed. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Keywords|documentation | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30933] intrinsic: EXIT
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-14 04:45 --- The above commit fixes the documentation to document that only default integer arguments are allowed. I left the argument name as STATUS, because COUNT seems absurd and in this case I think it's clear that we want to fix the implementation. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-14 04:47 --- The above commit is obviously missing; I typoed the PR number when making it. Here's the info: Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #8 from brooks at gcc dot gnu dot org 2007-03-14 04:47 --- Those last two commits should have gone to PR 30933. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-12 20:03 --- Subject: Bug 30635 Author: brooks Date: Mon Mar 12 20:03:33 2007 New Revision: 122861 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122861 Log: PR 30635 * doc/install.texi: Document --enable-stage1-languages Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-12 20:09 --- Fixed, as per the previous comment. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 09:42:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #14 from brooks at gcc dot gnu dot org 2007-03-09 22:21 --- Since this isn't a regression, the fix won't be backported to 4.1; thus, I'm closing this as fixed. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #10 from brooks at gcc dot gnu dot org 2007-03-09 04:50 --- See http://gcc.gnu.org/ml/fortran/2007-03/msg00155.html for a proposed patch. I'll attach it here, as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-09 04:51 --- Created an attachment (id=13175) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13175action=view) Fixincludes patch to fix _mingw.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-06 19:41:39 |2007-03-05 18:57:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug other/31050] New: gcc --version reports wrong year.
As per a message by David Taylor on gcc-patches, gcc --version reports the wrong copyright year: ../bin-4.2/bin/gcc --version gcc (GCC) 4.2.0 20070305 (prerelease) 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. He proposes a patch, but notes that he does not have access to the repository; see: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00296.html -- Summary: gcc --version reports wrong year. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other AssignedTo: brooks at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] gcc --version reports wrong year.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 19:38:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug fortran/30437] [4.1/4.2 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-05 20:17 --- Subject: Bug 30437 Author: brooks Date: Mon Mar 5 20:17:23 2007 New Revision: 122572 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122572 Log: fortran/ PR fortran/30437 Backport from trunk: 2007-01-25 Manuel Lopez-Ibanez [EMAIL PROTECTED] * lang.opt (Wall): Remove RejectNegative. * options.c (gfc_handle_option): Wall can be disabled. (set_Wall): Add a parameter for disabling Wall. testsuite/ PR fortran/30437 Backport from trunk: 2007-01-25 Manuel Lopez-Ibanez [EMAIL PROTECTED] * gcc.dg/Wall.c: New. * gcc.dg/Wno-all.c: New. * gfortran.dg/Wall.f90: New. * gfortran.dg/Wno-all.f90: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/Wall.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/Wno-all.c branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/Wall.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/Wno-all.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/30437] [4.1 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #12 from brooks at gcc dot gnu dot org 2007-03-05 20:18 --- Fixed in 4.2. -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|brooks at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.1/4.2 Regression] -Wno- |[4.1 Regression] -Wno-all is |all is rejected (even when |rejected (even when fortran |fortran is not included)|is not included) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #13 from brooks at gcc dot gnu dot org 2007-03-05 20:20 --- As of now, -fmax-errors has been backported to 4.2; it was committed to trunk some months ago. This at least masks this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug other/31050] gcc --version reports wrong year.
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-05 20:37 --- Subject: Bug 31050 Author: brooks Date: Mon Mar 5 20:37:05 2007 New Revision: 122574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122574 Log: PR 31050 * gcc.c: Correct copyright date in --version output. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-05 20:43 --- Fixed in 4.2; currently regtesting in mainline. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|NEW |ASSIGNED Known to work||4.2.0 Last reconfirmed|2007-03-05 19:38:45 |2007-03-05 20:43:42 date|| Summary|gcc --version reports wrong |[4.1/4.3] gcc --version |year. |reports wrong year. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #4 from brooks at gcc dot gnu dot org 2007-03-05 21:36 --- An identical bug also affects gfortran --version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-06 07:35 --- Subject: Bug 31050 Author: brooks Date: Tue Mar 6 07:35:28 2007 New Revision: 122597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122597 Log: PR 31050 * gfortranspec.c (lang_specific_driver): Update program name and copyright date. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] [4.1] gcc --version reports wrong year.
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-06 07:39 --- Both the gcc --version and gfortran --version problems are fixed on 4.3 and 4.2, and as per Steve Kargl's commit, the gfortran version bug is fixed on 4.1. The gcc --version bug is still outstanding on 4.1, however. It should be a trivial backport, but I don't have a tree for testing it. -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|brooks at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to work|4.2.0 |4.2.0 4.3.0 Summary|[4.1/4.3] gcc --version |[4.1] gcc --version reports |reports wrong year. |wrong year. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug fortran/30437] [4.1/4.2 Regression] -Wno-all is rejected (even when fortran is not included)
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-14 05:49:41 |2007-03-05 07:35:03 date|| Summary|[4.0/4.1/4.2 Regression] - |[4.1/4.2 Regression] -Wno- |Wno-all is rejected (even |all is rejected (even when |when fortran is not |fortran is not included) |included) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/30752] New: SECNDS() or DATE_AND_TIME() intrinsic optimized incorrectly.
Consider the following piece of code, derived from the secnds-1.f test case
(with some changes I'd added to avoid the 20ms arbitrary tolerance):
C {dg-do run}
character*20 dum1, dum2, dum3
real t1, t1a, t2, t2a
real dat1, dat2
integer i, j, values(8)
t1 = secnds (0.0)
call date_and_time (dum1, dum2, dum3, values)
t1a = secnds (0.0)
dat1 = 0.001*real (values(8)) + real (values(7)) +
60.0*real (values(6)) + 3600.0* real (values(5))
C The following line is critical here.
C write (*,*) (((dat1 - t1) 0.) .or. ((dat1 - t1) (t1a - t1)))
if (((dat1 - t1) 0.) .or. ((dat1 - t1) (t1a - t1))) then
write (*,*) (((dat1 - t1) 0.) .or. ((dat1 - t1) (t1a - t1)))
write (*,*) dat1, t1, t1a, dat1-t1, t1a-t1
call abort ()
end if
end
If I run this through the usual testsuite apparatus, it will fail on about 30%
(on average) of the optimized runs, but never (so far as I've seen) with -O0.
The output, though, usually looks like this:
F
16806.37 16806.37 16806.37 0.00 0.00
Note the F, for the exact check that just evaluated as true in the IF
statement.
If I uncomment the WRITE statement prior to the IF, the failures go away.
--
Summary: SECNDS() or DATE_AND_TIME() intrinsic optimized
incorrectly.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brooks at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30752
[Bug fortran/30752] SECNDS() or DATE_AND_TIME() intrinsic optimized incorrectly.
--- Comment #2 from brooks at gcc dot gnu dot org 2007-02-10 00:55 --- Yup, that seems to make the problem go away. Thanks! *** This bug has been marked as a duplicate of 323 *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30752
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #89 from brooks at gcc dot gnu dot org 2007-02-10 00:55 --- *** Bug 30752 has been marked as a duplicate of this bug. *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #12 from brooks at gcc dot gnu dot org 2007-02-07 09:10 --- (In reply to comment #7) If I read the F2003 standrad correctly, then your program conforms to F2003. You may want to change this to an enhancement request. This is incorrect -- the code does not conform to F2003 either. Section 9.11, paragraph 3, says that a recursive I/O statement -- that is, one that occurs while another is in progress, such as the print *, 'test' in this code -- may not identify an external unit, unless it is a child I/O statement. Section 9.5.3.7.1, paragarph 2, defines a child I/O statement as one that's occuring within a user-defined derived-type I/O function -- which is definitely not applicable here. Therefore, I believe that this bug should be closed as INVALID, but given the amount of commentary (and the fact that hanging is an unfortunate response even to invalid code), I'll let someone else make that call. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug c/30661] New: mayalias-2.c, mayalias-3.c fail at -O3 -g with --enable-checking=yes
With an --enable-checking=yes build of the tree at at svn 121332, the following testsuite errors appear: Executing on host: /home/brooks/gcc-callexpr/build2/gcc/xgcc -B/home/brooks/gcc-callexpr/build2/gcc/ /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c -w -O3 -g -fno-show-column -lm -o /home/brooks/gcc-callexpr/build2/gcc/testsuite/gcc/mayalias-2.x4(timeout = 300) /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal compiler error) [...] Executing on host: /home/brooks/gcc-callexpr/build2/gcc/xgcc -B/home/brooks/gcc-callexpr/build2/gcc/ /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c -w -O3 -g -fno-show-column -lm -o /home/brooks/gcc-callexpr/build2/gcc/testsuite/gcc/mayalias-3.x4(timeout = 300) /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compiler error) [...] -- Summary: mayalias-2.c, mayalias-3.c fail at -O3 -g with --enable- checking=yes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30661
