[Bug fortran/36581] New: Fortran compiler does not pass the tests
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Fortran Runtime Library configure 0.3, which was generated by GNU Autoconf 2.59. Invocation command line was $ /usr/local/src/gcc-4.3.1/libgfortran/configure --cache-file=./config.cache --enable-multilib --prefix=/usr/bin --enable-languages=c,c++,fortran,java,objc --program-transform-name=s,y,y, --with-target-subdir=ia64-unknown-linux-gnu --build=ia64-unknown-linux-gnu --host=ia64-unknown-linux-gnu --target=ia64-unknown-linux-gnu --srcdir=../../../gcc-4.3.1/libgfortran ## - ## ## Platform. ## ## - ## hostname = MCRD01.corpnet.singlebuoy.com uname -m = ia64 uname -r = 2.4.21-27.0.2.EL uname -s = Linux uname -v = #1 SMP Wed Jan 12 23:28:37 EST 2005 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = ia64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/kerberos/sbin PATH: /usr/kerberos/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/X11R6/bin PATH: /usr/ansys_inc/v100/ansys/bin PATH: /root/bin ## --- ## ## Core tests. ## ## --- ## configure:1390: loading cache ./config.cache configure:1519: checking build system type configure:1537: result: ia64-unknown-linux-gnu configure:1595: checking for --enable-version-specific-runtime-libs configure:1610: result: no configure:1614: checking for --enable-intermodule configure:1626: result: configure:1655: checking host system type configure:1669: result: ia64-unknown-linux-gnu configure:1677: checking target system type configure:1691: result: ia64-unknown-linux-gnu configure:1731: checking for a BSD-compatible install configure:1786: result: /usr/bin/install -c configure:1797: checking whether build environment is sane configure:1840: result: yes configure:1905: checking for gawk configure:1921: found /bin/gawk configure:1931: result: gawk configure:1941: checking whether make sets $(MAKE) configure:1961: result: yes configure:2121: checking whether to enable maintainer-specific portions of Makefiles configure:2130: result: no configure:2244: checking for ia64-unknown-linux-gnu-gcc configure:2270: result: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include configure:2552: checking for C compiler version configure:2555: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include --version /dev/null 5 xgcc (GCC) 4.3.1 Copyright (C) 2008 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. configure:2558: $? = 0 configure:2560: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include -v /dev/null 5 Reading specs from /usr/local/src/build-gcc-4.3.1/./gcc/specs Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.3.1/configure --prefix=/usr/bin Thread model: posix gcc version 4.3.1 (GCC) configure:2563: $? = 0 configure:2565: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include -V /dev/null 5 xgcc: '-V' must come at the start of the command line configure:2568: $? = 1 configure:2587: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include -o conftest -O2 -g -g -O2 conftest.c 5 configure:2590: $? = 0 configure:2624: checking for C compiler default output file name configure:2627: /usr/local/src/build-gcc-4.3.1/./gcc/xgcc -B/usr/local/src/build-gcc-4.3.1/./gcc/ -B/usr/bin/ia64-unknown-linux-gnu/bin/ -B/usr/bin/ia64-unknown-linux-gnu/lib/ -isystem /usr/bin/ia64-unknown-linux-gnu/include -isystem /usr/bin/ia64-unknown-linux-gnu/sys-include -O2 -g -g -O2 conftest.c 5 configure:2630: $? = 0 configure:2676: result: a.out configure:2681: checking whether the C compiler works
[Bug fortran/36581] Fortran compiler does not pass the tests
--- Comment #1 from Jean-Michel dot Male at sbmoffshore dot com 2008-06-20 07:47 --- Created an attachment (id=15792) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15792action=view) log produced by gcc when bootstrapping and compiling FC tests -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36581
[Bug fortran/36581] Fortran compiler does not pass the tests
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-06-20 07:49 --- From: http://gcc.gnu.org/install/prerequisites.html GNU Multiple Precision Library (GMP) version 4.1 (or later) Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include. From your config.log: /usr/local/src/build-gcc-4.3.1/./gcc/f951: relocation error: /usr/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36581
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #6 from dseketel at redhat dot com 2008-06-20 09:53 --- Created an attachment (id=15793) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15793action=view) rebase against current trunk Rebased against current trunk. -- dseketel at redhat dot com changed: What|Removed |Added Attachment #15780|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #5 from karx11erx at hotmail dot com 2008-06-20 09:58 --- (In reply to comment #3) Update your system. Report this bug to OpenSUSE. *** This bug has been marked as a duplicate of 35257 *** I have been searching around a little and found that the gjar used by openSUSE 10.3 belongs to a classpath package that is coming from gnu.org (http://www.gnu.org/software/classpath/). Seems pretty daft to me to claim this would be a bug I'd have to report to SUSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug fortran/36526] pointer in pure function
--- Comment #2 from pault at gcc dot gnu dot org 2008-06-20 10:43 ---
(In reply to comment #1)
This is due to an error in interface.c. The following fixes the fault,
bootstraps and regtests OK. I will apply as obvious just as soon as I can.
Paul
Index: gcc/fortran/interface.c
===
*** gcc/fortran/interface.c (revision 136870)
--- gcc/fortran/interface.c (working copy)
*** check_intents (gfc_formal_arglist *f, gf
*** 2379,2385
return FAILURE;
}
! if (a-expr-symtree-n.sym-attr.pointer)
{
gfc_error (Procedure argument at %L is local to a PURE
procedure and has the POINTER attribute,
--- 2379,2385
return FAILURE;
}
! if (f-sym-attr.pointer)
{
gfc_error (Procedure argument at %L is local to a PURE
procedure and has the POINTER attribute,
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-06-13 17:52:34 |2008-06-20 10:43:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #6 from karx11erx at hotmail dot com 2008-06-20 11:00 --- (In reply to comment #5) (In reply to comment #3) Update your system. Report this bug to OpenSUSE. *** This bug has been marked as a duplicate of 35257 *** I have been searching around a little and found that the gjar used by openSUSE 10.3 belongs to a classpath package that is coming from gnu.org (http://www.gnu.org/software/classpath/). Seems pretty daft to me to claim this would be a bug I'd have to report to SUSE. (In reply to comment #3) Update your system. Report this bug to OpenSUSE. *** This bug has been marked as a duplicate of 35257 *** Now this is great: I have found the latest classpath source, but: I have no clue where to have install put the stuff in - though that doesn't matter, because the install procedure needs several libraries in newer versions than I have installed on my system, and which do not seem to be available from SUSE. So I can either try to collect all that stuff from somewhere from the internet and install it manually, hoping it doesn't break my system, spending hours and hours of additional work with dubious prospect of success, or wait for SUSE to release gcc 4.3. All that because some not so smart people chose classpath over Sun's java libs for the sake of it being free, although it is not yet available in a version that indicates it would be stable, and that is at least 1.something. And all that is why? Because gcc 4.1 throws some errors on our code that works flawlessly with MS compilers and gcc 3, and that absolutely do not seem to be justified, and I wanted to make sure this problem is either fixed or still present in the latest gcc release in order to avoid remarks like update to the latest compiler version. I would so love to use Linux, but as soon as you leave the beaten path of common distros and are not an expert of sorts, you are completely lost with this operating system (I miss the system in this stuff). When will you Linux geeks learn to get your act together, if you ever want to offer a true alternative to Windows? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug java/35257] jar: internal error: java.lang.NullPointerException bootstrapping libjava
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-20 11:02 --- *** Bug 36576 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35257
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-20 11:02 --- Since the gjar you are using is from OpenSUSE, you should report this bug to them. *** This bug has been marked as a duplicate of 35257 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-06-20 11:04 --- Because gcc 4.1 throws some errors on our code that works flawlessly with MS compilers and gcc 3, and that absolutely do not seem to be justified, and I wanted to make sure this problem is either fixed or still present in the latest gcc release in order to avoid remarks like update to the latest compiler version. Have you read the changes pages? Start with http://gcc.gnu.org/gcc-3.4/changes.html and then read http://gcc.gnu.org/gcc-4.0/changes.html and then http://gcc.gnu.org/gcc-4.1/changes.html . Most likely your C++ code is not really standard C++ after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug fortran/36582] New: Namelist error
The problem is caused by the presence of nested derived types in a component which appears in a namelist. -- Summary: Namelist error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fmuldoo at me dot lsu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug fortran/36582] Namelist error
--- Comment #1 from fmuldoo at me dot lsu dot edu 2008-06-20 11:46 --- Created an attachment (id=15794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15794action=view) very short example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #7 from dseketel at redhat dot com 2008-06-20 12:05 --- (From update of attachment 15793) This version of the patch got sent to the mailing list at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01329.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-20 12:27 --- CONFIRM. The read file contains (see comments in the attached file): info_adjoint adjoint%solver_type='direct'/ Fortran runtime error: Cannot match namelist object name 'direct' The file works with other F95 compilers and is thus presumably valid; however, it is no regression. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Severity|blocker |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.3 4.2.1 4.3.1 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-06-20 12:27:53 date|| Summary|Namelist error |Namelist I/O error: Bogus ||Cannot match namelist ||object http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #9 from karx11erx at hotmail dot com 2008-06-20 12:28 ---
(In reply to comment #8)
Because gcc 4.1 throws some errors on our
code that works flawlessly with MS compilers and gcc 3, and that absolutely
do
not seem to be justified, and I wanted to make sure this problem is either
fixed or still present in the latest gcc release in order to avoid remarks
like
update to the latest compiler version.
Have you read the changes pages?
Start with http://gcc.gnu.org/gcc-3.4/changes.html and then read
http://gcc.gnu.org/gcc-4.0/changes.html and then
http://gcc.gnu.org/gcc-4.1/changes.html . Most likely your C++ code is not
really standard C++ after all.
Which rule is forbidding this:
template class T class CTest {
struct test {
int i;
} test *testptr;
};
--
karx11erx at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #3 from fmuldoo at me dot lsu dot edu 2008-06-20 12:32 --- Subject: Re: Namelist I/O error: Bogus Cannot match namelist object Hello, I am not sure what is meant by regression. Am I correct in assuming that you do not regard it as an error? Regards, Frank On Fri, 2008-06-20 at 12:27 +, burnus at gcc dot gnu dot org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2008-06-20 12:27 --- CONFIRM. The read file contains (see comments in the attached file): info_adjoint adjoint%solver_type='direct'/ Fortran runtime error: Cannot match namelist object name 'direct' The file works with other F95 compilers and is thus presumably valid; however, it is no regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #10 from karx11erx at hotmail dot com 2008-06-20 12:33 ---
(In reply to comment #9)
(In reply to comment #8)
Because gcc 4.1 throws some errors on our
code that works flawlessly with MS compilers and gcc 3, and that
absolutely do
not seem to be justified, and I wanted to make sure this problem is
either
fixed or still present in the latest gcc release in order to avoid
remarks like
update to the latest compiler version.
Have you read the changes pages?
Start with http://gcc.gnu.org/gcc-3.4/changes.html and then read
http://gcc.gnu.org/gcc-4.0/changes.html and then
http://gcc.gnu.org/gcc-4.1/changes.html . Most likely your C++ code is not
really standard C++ after all.
Which rule is forbidding this:
template class T class CTest {
struct test {
int i;
} test *testptr;
};
(In reply to comment #8)
Because gcc 4.1 throws some errors on our
code that works flawlessly with MS compilers and gcc 3, and that absolutely
do
not seem to be justified, and I wanted to make sure this problem is either
fixed or still present in the latest gcc release in order to avoid remarks
like
update to the latest compiler version.
Have you read the changes pages?
Start with http://gcc.gnu.org/gcc-3.4/changes.html and then read
http://gcc.gnu.org/gcc-4.0/changes.html and then
http://gcc.gnu.org/gcc-4.1/changes.html . Most likely your C++ code is not
really standard C++ after all.
There is also no ambiguity in this:
templateclass T CBaseT
{
protected:
T *i;
};
templateclass T CDerived : public CBaseT
{
inline T* foo (void) { return const_cast T* i; }
}
Yet it only compiles if it is defined like this:
templateclass T CDerived : public CBaseT
{
inline T* foo (void) { return const_castT* this-i; }
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-06-20 12:37
---
There is also no ambiguity in this:
Why that is invalid code is shown on http://gcc.gnu.org/gcc-3.4/changes.html .
(In reply to comment #9)
Which rule is forbidding this:
template class T class CTest {
struct test {
int i;
} test *testptr;
};
For this, you have a variable that is test and then *testptr which does not
make sense. Try it in a non template and you will see that it is invalid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #12 from karx11erx at hotmail dot com 2008-06-20 13:03 ---
(In reply to comment #11)
There is also no ambiguity in this:
Why that is invalid code is shown on http://gcc.gnu.org/gcc-3.4/changes.html .
(In reply to comment #9)
Which rule is forbidding this:
template class T class CTest {
struct test {
int i;
} test *testptr;
};
For this, you have a variable that is test and then *testptr which does not
make sense. Try it in a non template and you will see that it is invalid
code.
I have read the rule that enforces this- dereferencing - for the sake of
resolving ambiguity. There is no ambiguity in the above declaration though.
The struct variable/pointer variable declaration declares two variables at
once, where the latter can be changed whenever seen fit. I can't see why it
shouldn't make sense (but I may add to my defense that I haven't written that
code and never would have written code like that: It is my ungrateful task to
make it fit for gcc 4). Anyway, gcc 4 is the only compiler we found yet to
reject this code. Well, stuff like that shouldn't appear to often, so we can
manually fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #4 from aldot at gcc dot gnu dot org 2008-06-20 13:33 --- (In reply to comment #3) Subject: Re: Namelist I/O error: Bogus Cannot match namelist object Hello, I am not sure what is meant by regression. Am I correct in assuming that you do not regard it as an error? Regards, Frank On Fri, 2008-06-20 at 12:27 +, burnus at gcc dot gnu dot org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2008-06-20 12:27 --- CONFIRM. The read file contains (see comments in the attached file): info_adjoint adjoint%solver_type='direct'/ Fortran runtime error: Cannot match namelist object name 'direct' The file works with other F95 compilers and is thus presumably valid; however, it is no regression. Frank, a regression is something that worked before but does no longer work. Tobias said that it is presumably valid code and that it does not work (but never did with gfortran). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-20 13:37 --- I will take a shot at this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-20 12:27:53 |2008-06-20 13:37:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug fortran/36577] Segmentation fault from gfortran compilation
--- Comment #6 from zhonghaij at yahoo dot com 2008-06-20 13:45 --- This code (coart.f) works fine on several SGI and SUN systems. On my mac, only gfortran is available. based on the error message, I extracted the component (start at line 12657) with problem and named as junk.f. However, compilation of junk.f is fine. This is the puzzle! (In reply to comment #0) I got an error message when compiling my code coart.f . Seems gfortran does not like the block data. But I tried to separate the component with problem (the attached junk.f), it was fine. Could you please tell me why? Here is what happened: [zjin:~/coart/spec] jin% gfortran -c coart.f coart.f:12657: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. [zjin:~/coart/spec] jin% gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070518/configure --enable-languages=fortran,c++ Thread model: posix gcc version 4.3.0 20070518 (experimental) Thank you in advance. (In reply to comment #0) I got an error message when compiling my code coart.f . Seems gfortran does not like the block data. But I tried to separate the component with problem (the attached junk.f), it was fine. Could you please tell me why? Here is what happened: [zjin:~/coart/spec] jin% gfortran -c coart.f coart.f:12657: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. [zjin:~/coart/spec] jin% gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070518/configure --enable-languages=fortran,c++ Thread model: posix gcc version 4.3.0 20070518 (experimental) Thank you in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36577
[Bug fortran/36577] Segmentation fault from gfortran compilation
--- Comment #7 from zhonghaij at yahoo dot com 2008-06-20 13:49 --- Subject: Re: Segmentation fault from gfortran compilation Yes, junk.f is fine though it is extracted from coart.f. This code (coart.f) works fine on several SGI and SUN systems. On my mac, only gfortran is available. based on the error message, I extracted the component (start at line 12657) with problem and named as junk.f. However, compilation of junk.f is fine. This is the puzzle! Thanks for help. Zhonghai --- On Thu, 6/19/08, jvdelisle at gcc dot gnu dot org [EMAIL PROTECTED] wrote: From: jvdelisle at gcc dot gnu dot org [EMAIL PROTECTED] Subject: [Bug fortran/36577] Segmentation fault from gfortran compilation To: [EMAIL PROTECTED] Date: Thursday, June 19, 2008, 8:49 PM --- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-20 03:49 --- junk.f compiles without error for me here. Do you have the gmp and mpfr libraries installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36577 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36577
[Bug fortran/36276] [4.3/4.4 Regression] possible issue with opening fortran files?
--- Comment #8 from lauras at gcc dot gnu dot org 2008-06-20 13:57 --- Subject: Bug 36276 Author: lauras Date: Fri Jun 20 13:57:00 2008 New Revision: 136989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136989 Log: 2008-06-20 Laurynas Biveinis [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/34908 PR fortran/36276 * scanner.c (preprocessor_line): do not call gfc_free for current_file-filename if it differs from filename. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug debug/34908] valgrind error indication from testsuite hashtab.c : htab_hash_string
--- Comment #2 from lauras at gcc dot gnu dot org 2008-06-20 13:57 --- Subject: Bug 34908 Author: lauras Date: Fri Jun 20 13:57:00 2008 New Revision: 136989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136989 Log: 2008-06-20 Laurynas Biveinis [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/34908 PR fortran/36276 * scanner.c (preprocessor_line): do not call gfc_free for current_file-filename if it differs from filename. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34908
[Bug fortran/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
--- Comment #15 from laurynas dot biveinis at gmail dot com 2008-06-20 14:00 --- Junk output and valgrind errors should be fixed by a patch for PR fortran/34908 and PR fortran/36276. The /tmp/... file name issue needs additional fixing though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-06-20 14:01
---
think of:
templateclass T struct CBaseT
{
protected:
T *i;
};
template struct CBaseint
{
protected: typedef int i;
};
templateclass T struct CDerived : public CBaseT
{
inline T* foo (void) { return const_cast T* i; }
}
What happens then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
--- Comment #5 from gnu_andrew at member dot fsf dot org 2008-06-20 14:34 --- Wha is this bug waiting on? The only clear bug I can see here is that the Classpath build system (not gcc's; Classpath ./configure is invoked by the surrounding gcj build) should be checking the version of gjdoc. GJDoc 0.7.8 and 0.7.9 should work with the version of Classpath in GCC 4.3. There is an issue with this missing the contents of external/jsr166 which is fixed in Classpath. Generating docs for these additional classes requires 0.7.9. Classpath 0.98 (and thus, probably GCC 4.4) will include GJDoc. The warnings are expected. GJDoc's parser can run through 1.5 code. It can't correctly parse it all yet, though it may be worth turning off some of these errors in the meantime. Patches welcome :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
[Bug fortran/36577] Segmentation fault from gfortran compilation
--- Comment #8 from kargl at gcc dot gnu dot org 2008-06-20 15:54 --- (In reply to comment #6) This code (coart.f) works fine on several SGI and SUN systems. On my mac, only gfortran is available. based on the error message, I extracted the component (start at line 12657) with problem and named as junk.f. However, compilation of junk.f is fine. This is the puzzle! AS requested by Daniel, you need to provide all the necessary files. troutmask:kargl[202] gfc -c coart.f coart.f:13595.72: USE PMOM_aer 1 Fatal Error: Can't open module file 'pmom_aer.mod' for reading at (1): No such file or directory There is at least one file that defines PMOM_aer that is needed. [zjin:~/coart/spec] jin% gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070518/configure --enable-languages=fortran,c++ Thread model: posix gcc version 4.3.0 20070518 (experimental) Try updating your version of gfortran. 20070518 is over a year old, and there have been numerous bug fixes and changes in the last year. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36577
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #111 from vincent at vinc17 dot org 2008-06-20 16:09 --- (In reply to comment #109) WHERE'S THE BUG This is really not a GCC bug. The bug is actually in the x87 FPU because it doesn't obey the IEEE standard. Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard, which *allows* extended precision, and double precision is *available*. In fact, one could say that GCC even obeys the IEEE standard (which doesn't define bindings: the definition of destination page 4 of the IEEE754-1985 standard is rather vague and lets the language to define it exactly), but it doesn't obey the ISO C99 standard on some point. Concerning the x87 FPU: One can say however that the x87 is a badly designed because it is not possible to statically specify the precision. Nevertheless the OS/language implementations should take care of this problem. Note: the solution chosen by some OS'es (*BSD, MS-Windows...) is to configure the processor to the IEEE double precision by default (thus long double is also in double precision, but this is OK as far as the C language is concerned, there's still a problem with float, but in practice, nobody cares AFAIK). If you wish to compile for processors which don't have SSE, you have a few possibilities: (1) A very simple solution: Use long double everywhere. This avoids the bug, but this is not possible for software that requires double precision exactly, e.g. XML tools that use XPath. See other examples here: http://www.vinc17.org/research/extended.en.html Also this makes maintenance of software more difficult because long double can be much slower on some platforms, which support this type in software to provide more precision (e.g. PowerPC Linux and Mac OS X implement a double-double arithmetic, Solaris and HPUX implement quadruple precision). (But be careful when transfering binary data in long double format between computers because this format is not standardized and so the concrete bit representations vary between different CPU architectures.) Well, this is not specific to long double anyway: there exist 3 possible endianess for the double format (x86, PowerPC, ARM). (2) A partial but simple solution: Do comparisons on volatile variables only. Yes (but this is also a problem concerning the maintenance of portable programs). (4) A complex solution: [...] Yes, this is the workaround I use in practice. RECOMMENDATIONS I think this problem is really serious and general. Therefore, programmers should be warned soon enough. Yes, but note that this is not the only problem with compilers. See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578 for a bug related to casts to long double on x86_64 and ia64. This one is now tested by: http://www.vinc17.org/software/tst-ieee754.c (which has also tested bug 323 for a long time). -- vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c/36583] New: ICE on 5282/5206 at -O2 [regression]
This is an ICE on valid code with gcc 4.3.1 which does not occur with gcc 4.2.4. m68k-rtems4.9-gcc is 4.3.1. With 4.2.4, I tried to duplicate this with -m5200 since the option set has changed. $ m68k-rtems4.9-gcc -fasm -c -mcpu=5206-O2 j1.c j1.c: In function 'dbGet': j1.c:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ m68k-rtems4.9-gcc -fasm -c -mcpu=5206-O1 j1.c -- Summary: ICE on 5282/5206 at -O2 [regression] Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: m68k-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
[Bug c/36583] ICE on 5282/5206 at -O2 [regression]
--- Comment #1 from joel at gcc dot gnu dot org 2008-06-20 16:20 --- Created an attachment (id=15795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15795action=view) Cut down test case This is a stripped down version of the code that tripped the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
[Bug target/36584] New: Stack is not aligned correctly in recursive function
The example that will be attached in the next comment exhibits a problem with recursive functions. It looks that gcc doesn't align stack correctly if the only remaining call (after inlining?) in the function is the call to itself. Compiling the test source with -O3 -m32 produces: sbisect: -4 -8 pushl %ebp movl%esp, %ebp -12 pushl %edi -16 pushl %esi -20 pushl %ebx -196subl$176, %esp movl32(%ebp), %eax ... movl%eax, 4(%esp) 0xC4!! callsbisect movl40(%ebp), %ecx ... offset from %esp at call site. This violates assumption that %esp is aligned to 16 bytes at call sites. When program recurses into the function, the frame gets unaligned, leading to segfaults when aligned insns are used to access the frame. -- Summary: Stack is not aligned correctly in recursive function Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug target/36584] Stack is not aligned correctly in recursive function
--- Comment #1 from ubizjak at gmail dot com 2008-06-20 16:40 --- Created an attachment (id=15796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15796action=view) test case The testcase, distilled from povray-3.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug c/36585] New: getaddrinfo and friends not work with c99
http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/6bcf1e13819aef7a# http://groups.google.com/group/comp.lang.c/browse_thread/thread/a51b90d9ed8580d6 Using the --std=c99 switch, programs using getaddrinfo and other IPv6-aware networking commands don't work: [ ~/src/_sandbox] gcc --std=c99 -Wall ipv6_test.c -o it ipv6_test.c: In function `main': ipv6_test.c:25: error: storage size of 'hints' isn't known ipv6_test.c:34: warning: implicit declaration of function `getaddrinfo' ipv6_test.c:38: error: dereferencing pointer to incomplete type ... Removing the switch cause the program to build, but if I use c99-specific programming then it will fail because of that. -- Summary: getaddrinfo and friends not work with c99 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathanb at vt dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36585
[Bug fortran/36586] New: configure: error: GNU Fortran is not working; please report a bug...
checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /INSTALL/x/gcc-4.3.1/BUILD/i686-pc-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/INSTALL/x/gcc-4.3.1/BUILD' make: *** [all] Error 2 compilation fails and stops at this point -- Summary: configure: error: GNU Fortran is not working; please report a bug... Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kanito73 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36586
[Bug fortran/36586] configure: error: GNU Fortran is not working; please report a bug...
--- Comment #1 from kanito73 at hotmail dot com 2008-06-20 18:59 --- Created an attachment (id=15797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15797action=view) Make output indicates to attach config.log file Make output indicates to attach config.log file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36586
[Bug c/36585] getaddrinfo and friends not work with c99
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-20 19:03 --- This is not a bug with GCC but an issue with glibc, ask them they provide the headers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36585
[Bug c++/36587] New: Feature: add warning for constructor call with discarded return.
This patch implements a ``-Wunused-objects'' warning which is triggered if a
constructor is called, and the returned object is thrown away.
This can happen by accident when a declaration for an object accidentally omits
a name. For instance:
{
trace_class (foo, ...);
// ^ missing name
}
Whereas it is common for C++ function calls to discard returned objects,
discarding the result of an explicit constructor call is most likely a mistake.
I developed a patch against GCC 4.1.1 for this (because that's the compiler
currently used by my organization). The patch doesn't include a documentation
update, just code.
--
Summary: Feature: add warning for constructor call with discarded
return.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug fortran/36586] configure: error: GNU Fortran is not working; please report a bug...
--- Comment #2 from kargl at gcc dot gnu dot org 2008-06-20 19:23 --- Please read the instruction on how to build GCC. Your config.log shows that you are trying to build gcc within its source directory. This is supported. $ ../configure --prefix=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36586
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
--- Comment #1 from kkylheku at gmail dot com 2008-06-20 19:23 --- Created an attachment (id=15798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15798action=view) Implements -Wunused-objects warning for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
--- Comment #2 from kkylheku at gmail dot com 2008-06-20 20:26 --- I should add that this is different from -Wunused-value, because I want this warning emitted even if the constructor (or its corresponding destructor) have side effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug fortran/36492] incorrect error when compiling
--- Comment #8 from clerman at fuse dot net 2008-06-20 20:32 --- Subject: Re: incorrect error when compiling Hello, I'm not sure if I mentioned in my original bug report that I'm downloading the trunk version for GNU/Linux for 64-bit AMD-compatible processors (x86_64) processors. I just downloaded the latest trunk version, which is GNU Fortran (GCC) 4.4.0 20080616 (experimental) [trunk revision 136838] Copyright (C) 2008 Free Software Foundation, Inc. The problem seems to still exist with this release. Do you have any idea when revision 136894 for this platform will be posted? Thanks for your assistance. Yours truly, Norm Clerman domob at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #7 from domob at gcc dot gnu dot org 2008-06-18 13:56 --- Committed patch and fixed as rev 136894. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug other/36579] gcc refuses to recognize libraries on the command line
--- Comment #3 from c94wjpn at gmail dot com 2008-06-20 23:13 --- Subject: Re: gcc refuses to recognize libraries on the command line I think you're mad. I won't be reporting any bugs to gcc until I see signs of intelligence coming from you people. w. On Thu, Jun 19, 2008 at 4:02 PM, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-19 15:02 --- Is libext.a an archive? If so this is not a bug as archives are only looked at once by the most linkers. You can use -Wl,--start-group -Wl,--end-group if you want to group libraries/objects to be looked at more than once. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36579 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36579
