[Bug c++/10200] Weird clash with same names in different scopes
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 06:03 --- This is almost the same as the case discussed in DR 141. In particular, we must determine whether node.foo is the start of a template, or not. [basic.lookup.classref] says that we look in the class of the object expression, i.e., XT::node. However, that's a dependent type. So, we don't actually try to lookup there. Thus, we then go on to do lookup in the scope of the containing postfix-expression, which finds the global template function. DR 141 suggests that we should not do the second lookup. However, this DR is still in the open state; the committee has taken no action as of yet. However, independently of that, [temp.names] says that when the object has a dependent type (as it does in this case), then the name is a template only if the template keyword is explicitly used. So, the compiler is definitely wrong in this case. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
[Bug c++/19317] [4.0/4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 06:25 --- Jason -- Please apply the work-around; it's the best we've got at present. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 06:39 --- Dave -- Thanks for clarifying that you are only seeing warning messages. That indicates that I've probably fixed the original bug, but there is some kind of secondary bug. I will see if I can reproduce. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 06:49 --- Dave -- I suspect that there is some PCH involvement here. In particular, the warnings you're seeing while compiling header_cassert are very surprising, in that the preprocessed source for that file does not contain the string _S_do_it. So, I think the problem is related to PCH. To fix that, I'll need a test case that I can reproduce in a cross environment; i.e., preprocessed source that I can turn into a PCH, and then some use of the PCH that produces the warnings. In any case, I'm going to test, and then check in, the latest patch, as lots of link-time warnings is better than link failures. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug tree-optimization/19903] ACATS cxa4006 cxa4017 fail at runtime
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 07:08 --- Subject: Bug 19903 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 07:06:26 Modified files: gcc: ChangeLog tree-chrec.c Log message: PR tree-optimization/19903 * tree-chrec.c (chrec_convert): Return chrec_dont_know for constants that don't fit in their type after conversion. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8137r2=2.8138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gccr1=2.13r2=2.14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19903
[Bug tree-optimization/19903] ACATS cxa4006 cxa4017 fail at runtime
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 07:11 --- Subject: Bug 19903 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 07:09:57 Modified files: gcc: ChangeLog tree-chrec.c Log message: PR tree-optimization/19903 * tree-chrec.c (chrec_convert): Return chrec_dont_know for constants that don't fit in their type after conversion. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.124r2=2.7592.2.125 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.12.12.1r2=2.12.12.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19903
[Bug libfortran/20744] size= isn't implemented correctly
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-05 07:17 --- This is fixed with http://gcc.gnu.org/bugzilla/attachment.cgi?id=8525action=view (an attachment to PR 20661). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
[Bug tree-optimization/19903] ACATS cxa4006 cxa4017 fail at runtime
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-05 07:18 --- See http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02709.html -- What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19903
[Bug c++/20763] New: [4.0 regression] Incompatible struct alignment change
C++ structure layout has changed and is now incompatible between C++ and Java, and between older releases of C++. Structure layout is also incompatible with C. This is an ABI breaking bug. See the discussion beginning at http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html and the testcase at http://gcc.gnu.org/ml/gcc/2005-04/msg00152.html -- Summary: [4.0 regression] Incompatible struct alignment change Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org CC: aph at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org,pinskia at physics dot uc dot edu GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20763
[Bug c++/20763] [4.0 regression] Incompatible struct alignment change
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-05 08:54 --- Created an attachment (id=8535) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8535action=view) A test case If you run the appended code with g++ version 3.4.1, you get $ g++ -m32 thing.cc -save-temps ./a.out 56 With 4.0, you get $ PATH=/local/aph/install/bin/:$PATH g++ -m32 thing.cc -save-temps -fabi-version=0 ./a.out 52 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20763
[Bug fortran/20713] Not pad parameter strings.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 08:55 --- Subject: Bug 20713 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 08:54:50 Modified files: gcc/fortran: array.c decl.c match.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr15959.f90 string_pad_trunc.f90 Log message: 2005-04-05 Feng Wang [EMAIL PROTECTED] PR fortran/15959 PR fortran/20713 * array.c (resolve_character_array_constructor): New function. Set constant character array's character length. (gfc_resolve_array_constructor): Use it. * decl.c (add_init_expr_to_sym): Set symbol and initializer character length. (gfc_set_constant_character_len): New function. Set constant character expression according the given length. * match.h (gfc_set_constant_character_len): Add prototype. 2005-04-05 Feng Wang [EMAIL PROTECTED] * gfortran.dg/pr15959.f90: New test. * gfortran.dg/string_pad_trunc.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/array.c.diff?cvsroot=gccr1=1.13r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gccr1=1.33r2=1.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gccr1=1.10r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5282r2=1.5283 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr15959.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/string_pad_trunc.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20713
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 08:55 --- Subject: Bug 15959 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 08:54:50 Modified files: gcc/fortran: array.c decl.c match.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr15959.f90 string_pad_trunc.f90 Log message: 2005-04-05 Feng Wang [EMAIL PROTECTED] PR fortran/15959 PR fortran/20713 * array.c (resolve_character_array_constructor): New function. Set constant character array's character length. (gfc_resolve_array_constructor): Use it. * decl.c (add_init_expr_to_sym): Set symbol and initializer character length. (gfc_set_constant_character_len): New function. Set constant character expression according the given length. * match.h (gfc_set_constant_character_len): Add prototype. 2005-04-05 Feng Wang [EMAIL PROTECTED] * gfortran.dg/pr15959.f90: New test. * gfortran.dg/string_pad_trunc.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/array.c.diff?cvsroot=gccr1=1.13r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gccr1=1.33r2=1.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gccr1=1.10r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5282r2=1.5283 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr15959.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/string_pad_trunc.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug fortran/20713] Not pad parameter strings.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 09:04 --- Subject: Bug 20713 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 09:03:51 Modified files: gcc/fortran: array.c decl.c match.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr15959.f90 string_pad_trunc.f90 Log message: 2005-04-05 Feng Wang [EMAIL PROTECTED] PR fortran/15959 PR fortran/20713 * array.c (resolve_character_array_constructor): New function. Set constant character array's character length. (gfc_resolve_array_constructor): Use it. * decl.c (add_init_expr_to_sym): Set symbol and initializer character length. (gfc_set_constant_character_len): New function. Set constant character expression according the given length. * match.h (gfc_set_constant_character_len): Add prototype. 2005-04-05 Feng Wang [EMAIL PROTECTED] * gfortran.dg/pr15959.f90: New test. * gfortran.dg/string_pad_trunc.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/array.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.13r2=1.13.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.31r2=1.31.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.10r2=1.10.36.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.100r2=1.5084.2.101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr15959.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/string_pad_trunc.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20713
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 09:04 --- Subject: Bug 15959 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 09:03:51 Modified files: gcc/fortran: array.c decl.c match.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr15959.f90 string_pad_trunc.f90 Log message: 2005-04-05 Feng Wang [EMAIL PROTECTED] PR fortran/15959 PR fortran/20713 * array.c (resolve_character_array_constructor): New function. Set constant character array's character length. (gfc_resolve_array_constructor): Use it. * decl.c (add_init_expr_to_sym): Set symbol and initializer character length. (gfc_set_constant_character_len): New function. Set constant character expression according the given length. * match.h (gfc_set_constant_character_len): Add prototype. 2005-04-05 Feng Wang [EMAIL PROTECTED] * gfortran.dg/pr15959.f90: New test. * gfortran.dg/string_pad_trunc.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/array.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.13r2=1.13.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.31r2=1.31.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.10r2=1.10.36.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.100r2=1.5084.2.101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr15959.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/string_pad_trunc.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-05 09:41 --- Well, the discussion on c.l.f. seems clear: the standard forbids this, but does not require that we issue an error. It may be worth accepting it with a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From jh at suse dot cz 2005-04-05 09:46 --- Subject: Re: [4.1 Regression] Many C++ testsuite failures on ia64-hpux --- Additional Comments From wilson at gcc dot gnu dot org 2005-04-05 04:04 --- The patch seems to have been incompletely checked in. The ChangeLog entry claims to be removing code from final.c, but the code is still there. I laboriously tracked down the problem to the fact that cgraphunit handles ADDR_EXPR but not FDESC_ADDR. Hence, only targets that use function descriptors are affected. Like IA-64. This sounds like reason for the failure. What precisely is the behaviour of FDESC_ADDR? (ie should I behave same way as if I see ADDR_EXPR - assume that address of the function has been taken and thus it is neccesary?). Honza -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 04:04:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug rtl-optimization/20527] [4.0 regression] Mishandling of postincrement causes bzip2 miscompilation.
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-05 09:47 --- I may need some special absolution to apply this to 4.0, because I get regressions for frv-elf there. Well, ok, it's actually a timeout, but on a 2.8GHz P4 host, nonetheless): WARNING: program timed out. FAIL: 21_strings/basic_string/append/char/3.cc execution test Hm, it's likely I had something else running the time the test failed (the current run, LAST_UPDATED Thu Mar 31 10:19:49 UTC 2005 was with the patch removed), so I'll check frv-elf again with the patch applied. Results at the end of the day; the current run is checking arm-elf and then there's sh-elf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20527
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 10:19
---
Subject: [PATCH] Fix PR preprocessor/19475
Hi!
This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn,
for ISO C99 if there is no whitespace between macro definition and
replacement, but replacement starts with a basic character set character.
Ok to commit?
Unfortunately, the testcases provided fail in dejagnu (although the
preprocessor behaviour is correct).
Executing on host: /usr/src/gcc/obj/gcc/xgcc -B/usr/src/gcc/obj/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c -std=iso9899:1990
-pedantic-errors -E -o macspace1.i(timeout = 300)
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:5:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:6:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:7:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:8:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:9:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:10:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:11:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:12:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:13:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:14:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:15:10: warning: missing
whitespace after the macro name
...
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 5)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 6)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 7)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 8)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 9)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 10)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 11)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 12)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 13)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 14)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 15)
...
Is there some limitation on how many bytes or error messages
dejagnu groks or something?
When I split the tests into 6 warnings (resp. errors) chunks, it succeeds.
I'm using dejagnu 1.4.4, expect 5.42.1 and tcl 8.4.7.
2005-04-05 Jakub Jelinek [EMAIL PROTECTED]
PR preprocessor/19475
* libcpp/macro.c (create_iso_definition): For ISO C99, don't
pedwarn if there is no whitespace between macro name and its
replacement, but the replacement starts with a basic character
set character.
* gcc.dg/cpp/macspace1.c: New test.
* gcc.dg/cpp/macspace2.c: New test.
--- gcc/libcpp/macro.c.jj 2005-03-17 13:39:12.0 +0100
+++ gcc/libcpp/macro.c 2005-04-05 11:39:57.0 +0200
@@ -1430,8 +1430,39 @@ create_iso_definition (cpp_reader *pfile
macro-fun_like = 1;
}
else if (ctoken-type != CPP_EOF !(ctoken-flags PREV_WHITE))
-cpp_error (pfile, CPP_DL_PEDWARN,
- ISO C requires whitespace after the macro name);
+{
+ /* While ISO C99 requires whitespace before replacement text
+in a macro definition, ISO C90 with TC1 allows there characters
+from the basic source character set. */
+ if (CPP_OPTION (pfile, c99))
+ cpp_error (pfile, CPP_DL_PEDWARN,
+ ISO C99 requires whitespace after the macro name);
+ else
+ {
+ int warntype = CPP_DL_WARNING;
+ switch (ctoken-type)
+ {
+ case CPP_ATSIGN:
+ case CPP_AT_NAME:
+ case CPP_OBJC_STRING:
+ /* '@' is not in basic character set. */
+ warntype = CPP_DL_PEDWARN;
+ break;
+ case CPP_OTHER:
+ /* Basic character set sans letters, digits and _. */
+ if (strchr (!\#%'()*+,-./:;=?[\\]^{|}~,
+ ctoken-val.str.text[0]) == NULL)
+ warntype = CPP_DL_PEDWARN;
+ break;
+ default:
+ /* All other tokens start with a character from basic
+character set. */
+ break;
+ }
+ cpp_error (pfile, warntype,
+missing whitespace after the macro name);
+ }
+}
if (macro-fun_like)
token = lex_expansion_token (pfile, macro);
--- gcc/gcc/testsuite/gcc.dg/cpp/macspace2.c.jj 2005-04-05 11:45:18.0
+0200
+++ gcc/gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 11:46:41.0
+0200
@@ -0,0 +1,65 @@
+/* PR
[Bug fortran/20755] gfortran - prints the same number with 1p4G12.3 two different ways
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-05 10:21 --- Confirmed. Further reduced test case is: $ cat pr20775.f write (*,2000) 0.0, 0.02 write (*,2000) 0.01, 0.02 2000 format (1P2G12.3) end $ gfortran pr20775.f ./a.out 0.00 0.200E-01 1.000E-02 2.000E-02 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 10:21:40 date|| Summary|gfortran - prints the same |gfortran - prints the same |number with 1p4G12.3 two|number with 1p4G12.3 two |different ways |different ways http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20755
[Bug tree-optimization/20076] [3.3/3.4/4.0/4.1 Regression] __builtin_return(__builtin_apply()) inlined incorrectly
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-05 11:19 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00497.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20076
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From neil at daikokuya dot co dot uk 2005-04-05 11:31 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek wrote:- Is there some limitation on how many bytes or error messages dejagnu groks or something? I think it gets confused by the column numbers; if you add -fno-columns (or whatever it is) the problem would probably go away. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-05 11:50 --- As per comment#23, it *is* still the same problem. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 11:57
---
Subject: Re: [PATCH] Fix PR preprocessor/19475
On Tue, Apr 05, 2005 at 08:32:58PM +0900, Neil Booth wrote:
Jakub Jelinek wrote:-
Is there some limitation on how many bytes or error messages
dejagnu groks or something?
I think it gets confused by the column numbers; if you add
-fno-columns (or whatever it is) the problem would probably
go away.
Thanks, you're right. With following incremental patch
it passes just fine (and fails with cc1 built without the patch).
diff -u gcc/testsuite/gcc.dg/cpp/macspace2.c
gcc/testsuite/gcc.dg/cpp/macspace2.c
--- gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 11:46:41.0
+0200
+++ gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 13:51:02.0
+0200
@@ -1,6 +1,6 @@
/* PR preprocessor/19475 */
/* { dg-do preprocess } */
-/* { dg-options -std=iso9899:1999 -pedantic-errors } */
+/* { dg-options -std=iso9899:1999 -pedantic-errors -fno-show-column } */
#define a! /* { dg-error requires whitespace } */
#define b /* { dg-error requires whitespace } */
diff -u gcc/testsuite/gcc.dg/cpp/macspace1.c
gcc/testsuite/gcc.dg/cpp/macspace1.c
--- gcc/testsuite/gcc.dg/cpp/macspace1.c2005-04-05 11:54:16.0
+0200
+++ gcc/testsuite/gcc.dg/cpp/macspace1.c2005-04-05 13:50:54.0
+0200
@@ -1,6 +1,6 @@
/* PR preprocessor/19475 */
/* { dg-do preprocess } */
-/* { dg-options -std=iso9899:1990 -pedantic-errors } */
+/* { dg-options -std=iso9899:1990 -pedantic-errors -fno-show-column } */
#define a! /* { dg-warning missing whitespace } */
#define b /* { dg-warning missing whitespace } */
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-04-05 12:06 --- Subject: Re: [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 06:49 --- Dave -- I suspect that there is some PCH involvement here. In particular, the warnings you're seeing while compiling header_cassert are very surprising, in that the preprocessed source for that file does not contain the string _S_do_it. So, I think the problem is related to PCH. To fix that, I'll need a test case that I can reproduce in a cross environment; i.e., preprocessed source that I can turn into a PCH, and then some use of the PCH that produces the warnings. In any case, I'm going to test, and then check in, the latest patch, as lots of link-time warnings is better than link failures. The warnings are from GCC: ginyu% grep used but never defined *.c decl2.c: cp_warning_at (inline function %qD used but never defined, decl); You could be right that this is a PCH problem and possibly configuring with --disable-libstdcxx-pch would help. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug fortran/20713] Not pad parameter strings.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 13:24 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20713
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 13:25 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 15959, which changed state. Bug 15959 Summary: ICE and assertion failure in trans-decl.c with character initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug c++/20764] New: value won't fit in type
Given the following C++ source code float fred = 1.0e50; The float data type maximum value is around 1.0e38 on my machine, so fred will not fit. gcc 3.4 snapshot for 20050401 fails to detect this. [EMAIL PROTECTED]:~/C++/Alphasrc ~/gnu/20050401/results/bin/g++ -g -c -O2 -Wall floatVal.cc [EMAIL PROTECTED]:~/C++/Alphasrc ~/gnu/20050401/results/bin/g++ -g -c -O2 -Wall -ansi -pedantic floatVal.cc Here is Intel icc 8.1 doing what I want [EMAIL PROTECTED]:~/C++/Alphasrc icc -c floatVal.cc floatVal.cc(2): warning #264: floating-point value does not fit in required floating-point type float fred = 1.0e50; ^ -- Summary: value won't fit in type Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: linux-pc-i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20764
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-05 14:01 --- (In reply to comment #7) (p.s., FWIW, I *think* log(a1) is the same for imag(a1) == -0 vs +0) Huhh? Not if real(a1) is negative. The branch cut conventionally runs along the negative real axis. For instance, C99 specifies so. In 7.3.3.2 it also specifies that there it should be continuous with the second quadrant: implementations shall map a cut so the function is continuous as the cut is approached coming around the finite endpoint fo the cut in a counter clockwise direction. At least in the absence of signs on zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug c++/20763] [4.0/4.1 regression] Incompatible struct alignment change
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-05 14:04 --- Mark, this seems to be caused by http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01720.html The attributes are attached to the cdk_id declarator which is stored inside of a cdk_pointer declarator, but grokdeclarator only looks at declarator-attributes of the non-cdk_id declarators and so the attributes get lost. I'm not sure where is the best place to handle these, so will work on g++.dg-struct-layout-1 testsuite which ought to catch such ABI changes instead. -- What|Removed |Added CC||jakub at gcc dot gnu dot org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20763
[Bug libfortran/20755] gfortran - prints the same number with 1p4G12.3 two different ways
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 14:20 --- Subject: Bug 20755 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 14:20:11 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Added files: gcc/testsuite/gfortran.dg: pr20755.f Log message: PR libfortran/20755 * write.c (write_float): A G edit descriptor may locally change the scale factor, but it needs to be restored afterwards. * gfortran.dg/pr20755.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5283r2=1.5284 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20755.f.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.181r2=1.182 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gccr1=1.30r2=1.31 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20755
[Bug libfortran/20755] gfortran - prints the same number with 1p4G12.3 two different ways
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 14:24 --- Subject: Bug 20755 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 14:24:39 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Added files: gcc/testsuite/gfortran.dg: pr20755.f Log message: PR libfortran/20755 * write.c (write_float): A G edit descriptor may locally change the scale factor, but it needs to be restored afterwards. * gfortran.dg/pr20755.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.101r2=1.5084.2.102 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20755.f.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.14r2=1.163.2.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23.2.5r2=1.23.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20755
[Bug c/20764] value won't fit in type
-- What|Removed |Added Severity|normal |enhancement Component|c++ |c Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20764
[Bug libfortran/20755] gfortran - prints the same number with 1p4G12.3 two different ways
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-05 14:33 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20755
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From pcarlini at suse dot de 2005-04-05 14:36 --- Ok, you are right (forgot that your testcases is for negative real part): then the imaginary part of the log changes from +Pi to -Pi, since it's equal to arg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
-- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug rtl-optimization/20527] [4.0 regression] Mishandling of postincrement causes bzip2 miscompilation.
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-05 14:47 --- Without special approval, I'm not going to apply this to 3.4, because it causes a regression for v850-unknown-elf there, doubly confirmed, i.e. by reverting the patch and noticing the failure disappear: FAIL: g77.f-torture/execute/10197.f execution, -O0 (Regarding 4.0, a frv-elf re-test run is in progress.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20527
[Bug tree-optimization/20598] [4.1 regression] gcc.c-torture/unsorted/uuarg.c, -O3
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-05 14:50 --- Was still there for CRIS and MMIX with with LAST_UPDATED Mon Mar 28 03:18:05 UTC 2005. Gone for CRIS and MMIX with Mon Mar 28 13:26:33 UTC 2005, assumed fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20598
[Bug target/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
-- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 14:59 --- (In reply to comment #25) As per comment#23, it *is* still the same problem. But it is not as the x86 one was about combine generating bad subregs but combine in this case is not generating bad subregs but (mem (mem symbol_ref )), There are a couple of different bugs about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug bootstrap/20765] New: c4x port doesn't build
When I try to build gcc with bintuils, I get the following error message. In file included from /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.c:38: /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind.h:59: error: unable to emulate $-1òøDIòù In file included from /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.c:40: /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-pe.h: In function $-1òøread_encoded_value_with_baseòù: /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-pe.h:190: error: unable to emulate $-1òøSIòù /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-pe.h:191: error: unable to emulate $-1òøDIòù /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-pe.h:193: error: unable to emulate $-1òøSIòù /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-pe.h:194: error: unable to emulate $-1òøDIòù In file included from /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.c:41: /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.h: At top level: /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.h:112: error: unable to emulate $-1òøSIòù /home/kazu/gnu/gcc/gcc-develop/gcc/gcc/unwind-dw2-fde.h:113: error: unable to emulate $-1òøSIòù Here is a reduced test case. typedef unsigned _Unwind_Exception_Class __attribute__((__mode__(__DI__))); -- Summary: c4x port doesn't build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: c4x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20765
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 15:40 --- Subject: Bug 19159 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 15:40:18 Modified files: gcc/cp : ChangeLog decl2.c Log message: PR c++/19159 * decl2.c (import_export_decl): Use non-COMDAT external linkage for virtual tables, typeinfo, etc. that will be emitted in only one translation unit on systems without weak symbols. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4688r2=1.4689 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.772r2=1.773 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 15:46 --- I have checked in the patch to resolve the link failures, but I will leave this bug open until we've had a chance to analyze the warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug c++/20763] [4.0/4.1 regression] Incompatible struct alignment change
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20763
[Bug c++/20584] [4.0/4.1 Regression] inline function used but never defined
-- What|Removed |Added OtherBugsDependingO||19159 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20584
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 16:30 --- (In reply to comment #28) I have checked in the patch to resolve the link failures, but I will leave this bug open until we've had a chance to analyze the warnings. I would think this is the same as PR 20584 where there is a testcase but nobody has reduced it since it has to do with #pragma implementation and if you get rid of all the file markers aka # file line, it goes away. -- What|Removed |Added BugsThisDependsOn||20584 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug libfortran/20766] New: gfortran - run time error when calling fortran subroutine from c
We do this all of the time and g77, Absoft, IBM etc... do not complain.
[dranta:~/tests/gfortran] dir% gcc -c callc.c
[dranta:~/tests/gfortran] dir% g77 -c callf.f
[dranta:~/tests/gfortran] dir% g77 -o callc callc.o callf.o
[dranta:~/tests/gfortran] dir% callc
I am Here
[dranta:~/tests/gfortran] dir% gcc -c callc.c
[dranta:~/tests/gfortran] dir% gfortran -c callf.f
[dranta:~/tests/gfortran] dir% gfortran -o callc callc.o callf.o
[dranta:~/tests/gfortran] dir% callc
Fortran runtime error: End of record
[dranta:~/tests/gfortran] dir% cat callc.c
#include stdio.h
int main()
{
sub_();
}
[dranta:~/tests/gfortran] dir% cat callf.f
subroutine sub()
write(*,*)' I am Here '
return
end
[dranta:~/tests/gfortran] dir% which gcc
/Users/dir/gfortran/bin/gcc
--
Summary: gfortran - run time error when calling fortran
subroutine from c
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
[Bug rtl-optimization/20527] [4.0 regression] Mishandling of postincrement causes bzip2 miscompilation.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 16:39 --- Subject: Bug 20527 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 16:39:14 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: pr20527-1.c Log message: PR rtl-optimization/20527 * gcc.c-torture/execute/pr20527-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.102r2=1.5084.2.103 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr20527-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20527
[Bug libfortran/20766] gfortran - run time error when calling fortran subroutine from c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 16:42 --- I think you need to call set_args (argc, argv); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
[Bug libfortran/20766] gfortran - run time error when calling fortran subroutine from c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 16:44 --- actually this is a darwin specific bug, related to how lazy loading works. I will look into it. It works correctly on i686-pc-linux-gnu. -- What|Removed |Added GCC host triplet|powerpc-apple-darwin7.8.0 | GCC target triplet||powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
[Bug rtl-optimization/20527] [4.0 regression] Mishandling of postincrement causes bzip2 miscompilation.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 16:46 --- Subject: Bug 20527 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 16:45:56 Modified files: gcc: ChangeLog combine.c Log message: PR rtl-optimization/20527 * combine.c (can_combine_p) [AUTO_INC_DEC]: When INSN has an REG_INC note, test that the register also isn't mentioned in PRED or SUCC. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.127r2=2.7592.2.128 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.475.4.2r2=1.475.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20527
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From zack at codesourcery dot com 2005-04-05 16:49 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek [EMAIL PROTECTED] writes: Hi! This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn, for ISO C99 if there is no whitespace between macro definition and replacement, but replacement starts with a basic character set character. Ok to commit? OK except please remove the ?, ?, ?=, ?= testcases as those tokens are probably going to be removed in the near future. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug rtl-optimization/20527] [4.0 regression] Mishandling of postincrement causes bzip2 miscompilation.
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-05 16:51 --- No 3.4 commit and now committed to 4.0 too (the frv-elf timeout failure was not repeatable): closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20527
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 16:54 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 On Tue, Apr 05, 2005 at 09:49:19AM -0700, Zack Weinberg wrote: This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn, for ISO C99 if there is no whitespace between macro definition and replacement, but replacement starts with a basic character set character. Ok to commit? OK except please remove the ?, ?, ?=, ?= testcases as those tokens are probably going to be removed in the near future. I know, but that IMHO shouldn't matter for the testcase. #define a? should be still treated like #define a ? in C90 (with a warning), no matter whether ? is a cpp token or 2 tokens. Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From zack at codesourcery dot com 2005-04-05 17:05 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek [EMAIL PROTECTED] writes: On Tue, Apr 05, 2005 at 09:49:19AM -0700, Zack Weinberg wrote: This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn, for ISO C99 if there is no whitespace between macro definition and replacement, but replacement starts with a basic character set character. Ok to commit? OK except please remove the ?, ?, ?=, ?= testcases as those tokens are probably going to be removed in the near future. I know, but that IMHO shouldn't matter for the testcase. #define a? should be still treated like #define a ? in C90 (with a warning), no matter whether ? is a cpp token or 2 tokens. Sure, but it's redundant with = and so on. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug libfortran/20766] gfortran - run time error when calling fortran subroutine from c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 17:06 --- Ok, this is a darwin specific bug, really this is a just darwin specific. We need to add -single_module to the link when linking libgfortran.dyld. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 17:06:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
[Bug target/20025] Internal error while compiling
--- Additional Comments From dje at gcc dot gnu dot org 2005-04-05 17:08 --- I cannot duplicate this with GCC 3.3.3 on AIX, GCC 3.3-hammer on SLES9, GCC 3.4.4 on SLES9, or GCC 4.0 on SLES9. This may have been introduced after GCC 3.3.4 or 3.3.5, but it appears to have been fixed in more recent releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20025
[Bug ada/17527] Ada Bootstrap problem because of -Werror
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2005-04-05 17:26 --- Subject: Re: Ada Bootstrap problem because of -Werror Sorry for the delay. I've bootstrapped todays GCC with Ada and everything was fine, so it seem to be fixed, thanks. VH On Mon, 4 Apr 2005, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-04 04:47 --- It has been 3 months now, is this bug fixed or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
[Bug ada/17527] Ada Bootstrap problem because of -Werror
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 17:32 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
[Bug pch/20673] C PCH testsuite assembly comparison failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 17:33 --- Subject: Bug 20673 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-05 17:32:41 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: attrib21.C Log message: PR c++/20673 * decl.c (grokdeclarator): Correct attribute handling. PR c++/20673 * g++.dg/ext/attrib21.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.24r2=1.4648.2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1371.2.6r2=1.1371.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.103r2=1.5084.2.104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/attrib21.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug pch/20673] C PCH testsuite assembly comparison failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 17:36 --- Subject: Bug 20673 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 17:35:54 Modified files: gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/ext: attrib21.C Log message: PR c++/20673 * decl.c (grokdeclarator): Correct attribute handling. PR c++/20673 * g++.dg/ext/attrib21.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1382r2=1.1383 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/attrib21.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug c++/20763] [4.0/4.1 regression] Incompatible struct alignment change
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 17:38 --- Fixed in 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20763
[Bug tree-optimization/20767] New: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
FAIL: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 appears on hppa64-hpux and on ia64-hpux with -mlp64. gcc-testresults also shows it on powerpc64-linux-gnu, x86_64-linux-gnu and mips-irix with -mabi=64, so this appears to be a generic 64-bit problem. -- Summary: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: dberlin at gcc dot gnu dot org,dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug tree-optimization/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-05 17:56 --- Subject: Re: New: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems On Tue, 2005-04-05 at 17:44 +, jsm28 at gcc dot gnu dot org wrote: FAIL: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 appears on hppa64-hpux and on ia64-hpux with -mlp64. gcc-testresults also shows it on powerpc64-linux-gnu, x86_64-linux-gnu and mips-irix with -mabi=64, so this appears to be a generic 64-bit problem. Can you send me the dump file? I suspect it's eliminating 3 instead of 4 or something (and it's probably none of the eliminations we care about) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug tree-optimization/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 17:57 --- Or it might be elimitating 5 since there is an extra cast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug java/20768] New: Bytecode - native code doesn't handle exception properly
With the test case I will attach, I get different behaviour if I compile it first to bytecode *with ecj* and then natively compile it versus interpreting the bytecode (I have also tried going directly from source to native and that's the same behaviour as interpreted). The error does not happen with bytecode generated by gcj -C or Sun's javac. To duplicate (note: javac == ecj in case 1 and Sun's javac in case 2) 1. javac TestExceptionBug.java gcj -fPIC -fjni -findirect-dispatch --main=TestExceptionBug -o TestExceptionBug *.class gcj -fPIC -fjni -findirect-dispatch --main=TestExceptionBug -o nativeTestExceptionBug TestExceptionBug.java echo interpreted ; gij TestExceptionBug echo native (from source) ; ./nativeTestExceptionBug echo native (from bytecode) ; ./TestExceptionBug Output: interpreted Finally! It's happened to me -- Ce Ce Penniston Hi native (from source) Finally! It's happened to me -- Ce Ce Penniston Hi native (from bytecode) Finally! It's happened to me -- Ce Ce Penniston Exception in thread main TestExceptionBug$IndexedStoreException at TestExceptionBug.getIndex(java.lang.String) (Unknown Source) at TestExceptionBug.getIndex() (Unknown Source) at TestExceptionBug.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) 2. javac TestExceptionBug.java gcj -fPIC -fjni -findirect-dispatch --main=TestExceptionBug -o TestExceptionBug *.class gcj -fPIC -fjni -findirect-dispatch --main=TestExceptionBug -o nativeTestExceptionBug TestExceptionBug.java echo interpreted ; gij TestExceptionBug echo native (from source) ; ./nativeTestExceptionBug echo native (from bytecode) ; ./TestExceptionBug Output: interpreted Finally! It's happened to me -- Ce Ce Penniston Hi native (from source) Finally! It's happened to me -- Ce Ce Penniston Hi native (from bytecode) Finally! It's happened to me -- Ce Ce Penniston Hi $ gcj --version gcj (GCC) 4.0.0 20050402 (Red Hat 4.0.0-0.39) $ javac -version Eclipse Java Compiler 0.537, pre-3.1.0 milestone-5, Copyright IBM Corp 2000, 2005. All rights reserved. -- Summary: Bytecode - native code doesn't handle exception properly Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: overholt at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug java/20768] Bytecode - native code doesn't handle exception properly
--- Additional Comments From overholt at redhat dot com 2005-04-05 18:12 --- Created an attachment (id=8537) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8537action=view) Test case (boiled down from something we're seeing with Ecilpse) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug testsuite/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05
18:14 ---
The problem is that we eliminate 5 instead of 4.
Eliminated: 5
The easy fix to make sure that this does not fail on any target is the
following:
Index: gcc.dg/tree-ssa/ssa-pre-8.c
===
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-8.c,v
retrieving revision 1.1
diff -u -p -r1.1 ssa-pre-8.c
--- gcc.dg/tree-ssa/ssa-pre-8.c 4 Apr 2005 19:02:16 - 1.1
+++ gcc.dg/tree-ssa/ssa-pre-8.c 5 Apr 2005 18:14:07 -
@@ -5,7 +5,7 @@ struct s {
};
int
-foo (unsigned int i, struct s *array)
+foo (__SIZE_TYPE__ i, struct s *array)
{
int *p = array[i].n;
if (p)
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |testsuite
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-05 18:14:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug java/20768] Bytecode - native code doesn't handle exception properly
-- What|Removed |Added CC||bkonrath at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug rtl-optimization/20769] New: bt-load.c doesn't take nonlocal gotos into account.
While nonlocal gotos of the setjmp / longjmp variety are harmless, nonlocal gotos like in execute/nestfunc-6.c arrive at a label not associated with the call site, and hence the target registers can contain unexpected values. branch target register load migration must not hoist register loads past a nonlocal goto receiver of this kind. -- Summary: bt-load.c doesn't take nonlocal gotos into account. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20769
[Bug rtl-optimization/20769] bt-load.c doesn't take nonlocal gotos into account.
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-05 18:24 --- Created an attachment (id=8538) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8538action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20769
[Bug preprocessor/20770] New: Using -M -MT ... -MF ... with -g3 generates preprocess line to stdout
Found using gcc 3.4.2 on Fedora Core 3:
$ gcc -g3 -M -MT hello. -MF hello.d hello.c
# 1 /home/viz/src//
$
The line '# 1 /home/viz/src//' should not be generated.
Verified that the problem still exists in 3.4.3.
$ cat hello.c
#include stdio.h
int main () {
printf(Hello\n);
}
$ gcc -v -Wall -g3 -M -MT hello. -MF hello.d hello.c
Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/specs
Configured with: ./configure
Thread model: posix
gcc version 3.4.3
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/3.4.3/cc1 -E -quiet -v -M -MF
hello.d -MT hello.
-dD hello.c -mtune=k8 -Wall -fworking-directory
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/../../../../
x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/include
/usr/include
End of search list.
# 1 /home/viz/src//
$
Workaround: Don't use the -g3 option.
--
Summary: Using -M -MT ... -MF ... with -g3 generates preprocess
line to stdout
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ben at pathscale dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20770
[Bug java/20768] Bytecode - native code doesn't handle exception properly
--- Additional Comments From mckinlay at redhat dot com 2005-04-05 18:33 --- Confirmed. There seems to be something unique about the exception table generated by ecj which confuses gcj. Note that this happens both with or without optimization. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 18:33:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From hjl at lucon dot org 2005-04-05 18:36 --- A new patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00567.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug testsuite/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-05 18:41 --- Subject: Re: gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems On Tue, 2005-04-05 at 18:14 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 18:14 --- The problem is that we eliminate 5 instead of 4. Eliminated: 5 The easy fix to make sure that this does not fail on any target is the following: feel free to apply this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug testsuite/20771] New: Duplicate PCH test names
gcc.sum contains pairs of identical lines such as: PASS: gcc.dg/pch/common-1.c -O0 -g (test for excess errors) PASS: gcc.dg/pch/common-1.c -O0 -g (test for excess errors) The text after PASS: or FAIL: is a test name which is supposed to be unique, for the sake of regression testers matching up the same test in .sum files from different runs. One of these tests is with a .gch file and one without, so dg-pch.exp should give them names reflecting this, e.g. PASS: gcc.dg/pch/common-1.c -O0 -g with PCH (test for excess errors) PASS: gcc.dg/pch/common-1.c -O0 -g without PCH (test for excess errors) -- Summary: Duplicate PCH test names Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771
[Bug testsuite/20772] New: x86 tests should run on both i?86 and x86_64
There are i?86 targets which can use -m64 (i386-pc-solaris2.10) and x86_64 targets which can use -m32 (most or all of them). In both cases, --disable-multilib can be used so that only -m32, or only -m64 is available. Tests requiring 32-bit x86 can run on both i?86 and x86_64, as can tests requiring 64-bit, in both cases provided the right multilib is enabled. At present, many tests are enabled only for i?86, or only for x86_64; instead they should be enabled for both, restricted to ilp32 or lp64 as appropriate. In addition, it is inappropriate for tests to hardcode -m32 on x86_64 as i386-pentium4-not-mull.c, setjmp-2.c, short-compare-1.c, short-compare-2.c in gcc.dg do, because --disable-multilib can be used and those tests presently fail with --disable-multilib; instead, special options should be specified as appropriate for 32-bit x86 and it should be up to the testsuite user to run it with both -m32 and -m64 if they wish to do so. As noted at http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00199.html, x86, x86_ilp32 and x86_lp64 effective-target keywords would simplify fixing these issues, although there are still tests e.g. restricted to x86(_64)-linux-gnu as well as those which care about the CPU and not the OS. -- Summary: x86 tests should run on both i?86 and x86_64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i?86-*-*, x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20772
[Bug middle-end/18152] corrupted profile info after optimized compilation and --fprofile-use
--- Additional Comments From joc at presence-pc dot com 2005-04-05 19:44 --- Any news about this issue ? Thanks ! Jocelyn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18152
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-04-05 19:44 --- Subject: Re: [4.1 Regression] Many C++ testsuite failures on ia64-hpux jh at suse dot cz wrote: This sounds like reason for the failure. What precisely is the behaviour of FDESC_ADDR? (ie should I behave same way as if I see ADDR_EXPR - assume that address of the function has been taken and thus it is neccesary?). On IA-64, the address of a function is a two-word function descriptor, one word is the function entry point, and one word is the function's gp value. FDESC_EXPR is used to represent this. FDESC_EXPR must be used in places where the difference matters, e.g. in initializers for vtables. According to the docs in tree.def, operand0 of FDESC_EXPR is always a function, so it should be possible to handle FDESC_EXPR exactly the same as ADDR_EXPR if you don't care about the difference. That is what the untested patch I added to the PR does. It seems to work for the testcase. There is also the question of whether there are other places that need the same fix. I haven't looked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug java/20773] New: ICE: SEGV building jar file
I'm seeing the following: # gcj -O2 -shared -findirect-dispatch -Wl,-Bsymbolic -fPIC -o libtritonus.jar.so tritonus.jar org/tritonus/util/TCircularBuffer.java: In class 'org.tritonus.util.TCircularBuffer': org/tritonus/util/TCircularBuffer.java: In method 'org.tritonus.util.TCircularBuffer.read(byte[],int,int)': org/tritonus/util/TCircularBuffer.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. This works at -O0 and fails at -O1 and above. I will attach the jar file to this case. It comes from tritonus-0.3.0 which is Free Software. -- Summary: ICE: SEGV building jar file Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug java/20773] ICE: SEGV building jar file
--- Additional Comments From green at redhat dot com 2005-04-05 19:59 --- Created an attachment (id=8539) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8539action=view) Problem jar file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug tree-optimization/20773] ICE: SEGV building jar file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 20:05 --- This is a tree optimization problem: #0 add_phi_arg (phi=0x45d11380, def=0x43bb83c0, e=0x0) at /Users/pinskia/src/new-fold/gcc/ gcc/tree-phinodes.c:339 #1 0x000a91a4 in tree_duplicate_sese_region (entry=0x9, exit=0x45705cc0, region=0x421c67a0, n_region=1, region_copy=0x421c6900) at /Users/pinskia/src/new-fold/gcc/gcc/tree-cfg.c:5221 #2 0x001aea24 in copy_loop_headers () at /Users/pinskia/src/new-fold/gcc/gcc/tree-ssa-loop-ch.c: 208 #3 0x000bbf54 in execute_pass_list (pass=0x0) at /Users/pinskia/src/new-fold/gcc/gcc/tree- optimize.c:541 #4 0x000bbfdc in execute_pass_list (pass=0x0) at /Users/pinskia/src/new-fold/gcc/gcc/tree- optimize.c:579 -- What|Removed |Added Component|java|tree-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 20:07 --- Subject: Bug 19475 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 20:07:06 Modified files: gcc/testsuite : ChangeLog libcpp : ChangeLog macro.c Added files: gcc/testsuite/gcc.dg/cpp: macspace1.c macspace2.c Log message: PR preprocessor/19475 * macro.c (create_iso_definition): For ISO C99, don't pedwarn if there is no whitespace between macro name and its replacement, but the replacement starts with a basic character set character. * gcc.dg/cpp/macspace1.c: New test. * gcc.dg/cpp/macspace2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5287r2=1.5288 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gccr1=1.64r2=1.65 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/macro.c.diff?cvsroot=gccr1=1.11r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/cpp/macspace2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug fortran/20774] New: Debug information in .o (from FORTRAN) points to temporary file under certain circumstances
Compiling short subroutine below (with included .inc file) produces defective debug information referring to temporary file. Pre-processed file not included because -save-temps option (slightly) changes the nature of the problem, and compiling the preprocessed .f file will not exhibit the problem. ### begin cblock.inc ### REAL X,Y,Z COMMON /CBLOCK/ X,Y,Z ### end cblock.inc ### ### begin tsub.F ### subroutine tsub implicit none include 'cblock.inc' INTEGER I2 REAL F1 I2 = 3 F1 = 1.0 return end ### end tsub.F ### ### begin compile command ### g77 -fno-automatic -v -g -I. -c tsub.F ### end compile command ### ### begin compiler output ### g77 -fno-automatic -v -g -I. -c tsub.F Reading specs from /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../../gcc-3.4.3/configure --prefix=/tmp/build-gcc-v3_4_3 --disable-shared --with-gnu-ld --with-ld=/tmp/build-gcc-v3_4_3/bin/ld --with-gnu-as --disable-libgcj --with-as=/tmp/build-gcc-v3_4_3/bin/as --enable-threads=posix --enable-languages=c,c++,f77,objc Thread model: posix gcc version 3.4.3 /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -I. -iprefix /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/ -isystem /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/include tsub.F -mtune=pentiumpro -fno-automatic -fworking-directory -o /tmp/cc0zObeX.f ignoring nonexistent directory /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/include ignoring nonexistent directory /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /tmp/build-gcc-v3_4_3/include ignoring nonexistent directory /tmp/build-gcc-v3_4_3/lib/gcc/i686-pc-linux-gnu/3.4.3/include ignoring nonexistent directory /tmp/build-gcc-v3_4_3/i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: . /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/include /usr/local/include /usr/include End of search list. /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.3/f771 /tmp/cc0zObeX.f -quiet -dumpbase tsub.F -mtune=pentiumpro -auxbase tsub -g -version -fno-automatic -I. -o /tmp/ccmwNjKI.s GNU F77 version 3.4.3 (i686-pc-linux-gnu) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /afs/fnal.gov/ups/gcc/v3_4_3/Linux+2.4-2.3.2/bin/as -V -Qy -o tsub.o /tmp/ccmwNjKI.s GNU assembler version 2.14 (i686-pc-linux-gnu) using BFD version 2.14 20030612 ### end compiler output ### ### begin illustration of bug ### nm -Aal tsub.o | grep tmp tsub.o:0004 b f1.1 /tmp/cc0zObeX.f:9 ### end illustration of bug ### ### begin explanation ### Any symbol which gets debug information referring to a temporary file will probably be inaccessible in the debugger. Do *any* of the following things, and the problem goes away: 1) Remove the -fno-automatic switch 2) Include contents of cblock.inc in tsub.F 3) Remove the second of the two declarations in tsub.F (F1) 4) Replace the intrinsic include directive with #include Replacing: INTEGER I2 REAL F1 with INTEGER I1, I2 or INTEGER I1 INTEGER I2 preserves the problem (the missing symbol is I2, here). The non-optimal debugger behavior caused by this problem is the same with ddd/gdb and with totalview. This bug is present in gcc v3.4.1 and v3.4.3, but not in v3.3.1. ### end explanation ### -- Summary: Debug information in .o (from FORTRAN) points to temporary file under certain circumstances Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chissg at comcast dot net CC: gcc-bugs 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=20774
[Bug tree-optimization/20076] [3.3/3.4/4.0/4.1 Regression] __builtin_return(__builtin_apply()) inlined incorrectly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-05 20:10 --- Subject: Bug 20076 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-05 20:10:14 Modified files: gcc: ChangeLog tree-inline.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: builtin-apply4.c Log message: PR tree-optimization/20076 * tree-inline.c (inline_forbidden_p_1): Prevent inlining functions that call __builtin_return or __builtin_apply_args. * gcc.dg/builtin-apply4.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8149r2=2.8150 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gccr1=1.178r2=1.179 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5288r2=1.5289 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/builtin-apply4.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20076
[Bug java/20768] Bytecode - native code doesn't handle exception properly
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-05 20:15 --- Could you attach the ecj-generated bytecode for this file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug libgcj/20775] New: Crash in libgcj.so on linux alpha
gij crashes in GC
I am not sure which component to report this bug against.
I did some investigations and I got to the boehm-gc.
I checked the latest CVS gcc4_0-branch and tried to make check in
boehm-gc directory. The test crashed too.
# gij --version
gij (GNU libgcj) version 3.4.3 20050221 (Red Hat 3.4.3-20)
Copyright (C) 2002 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.
# gdb /usr/bin/gij
GNU gdb Red Hat Linux (6.3.0.0-1.6rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as alpha-redhat-linux-gnu...
(no debugging symbols found)
Using host libthread_db library /lib/tls/libthread_db.so.1.
(gdb) r org.eclipse.jdt.internal.compiler.batch.Main -bootclasspath
/usr/share/java/libgcj-3.4.3.jar Test.java
Starting program: /usr/bin/gij org.eclipse.jdt.internal.compiler.batch.Main
-bootclasspath /usr/share/java/libgcj-3.4.3.jar Test.java
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 2199023381872 (LWP 8734)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2199023381872 (LWP 8734)]
0x02b8f0a8 in GC_push_all_eager () from /usr/lib/libgcj.so.5
(gdb) bt
#0 0x02b8f0a8 in GC_push_all_eager () from /usr/lib/libgcj.so.5
#1 0x02b8f148 in GC_push_all_stack () from /usr/lib/libgcj.so.5
#2 0x02b99960 in GC_push_all_stacks () from /usr/lib/libgcj.so.5
#3 0x02b933d8 in GC_default_push_other_roots ()
from /usr/lib/libgcj.so.5
#4 0x02b90cbc in GC_push_roots () from /usr/lib/libgcj.so.5
#5 0x02b8fcec in GC_mark_some () from /usr/lib/libgcj.so.5
#6 0x02b84a88 in GC_stopped_mark () from /usr/lib/libgcj.so.5
#7 0x02b85704 in GC_try_to_collect_inner () from /usr/lib/libgcj.so.5
#8 0x02b91f68 in GC_init_inner () from /usr/lib/libgcj.so.5
#9 0x02b92260 in GC_init () from /usr/lib/libgcj.so.5
#10 0x02b8a58c in GC_init_gcj_malloc () from /usr/lib/libgcj.so.5
#11 0x02b81a08 in _Jv_InitGC () from /usr/lib/libgcj.so.5
#12 0x027dfd10 in _Jv_CreateJavaVM () from /usr/lib/libgcj.so.5
#13 0x027e01a4 in _Jv_RunMain () from /usr/lib/libgcj.so.5
#14 0x00012e54 in ?? ()
#15 0x020001139284 in __libc_start_main () from /lib/tls/libc.so.6.1
#16 0x00012b78 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
Test in boehm-gc.
[EMAIL PROTECTED] gc]# make check
Making check in include
make[1]: Entering directory `/opt/gcc/build/gc/include'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/opt/gcc/build/gc/include'
make[1]: Entering directory `/opt/gcc/build/gc'
gcc -DHAVE_CONFIG_H -I. -I../../boehm-gc -I./include -I./include
-I/opt/gcc/boehm-gc/include -fexceptions -Iinclude -I././targ-include
-I.//libc/include -g -O0 -c -o tests/test.o ../../boehm-gc/tests/test.c
/bin/sh ./libtool --mode=link gcc -fexceptions -Iinclude -I././targ-include
-I.//libc/include -g -O0 -o gctest -shared-libgcc tests/test.o ./libgcjgc.la
-lpthread -ldl
gcc -fexceptions -Iinclude -I././targ-include -I.//libc/include -g -O0 -o
.libs/gctest -shared-libgcc tests/test.o ./.libs/libgcjgc.so -lpthread -ldl
-Wl,--rpath -Wl,/usr/local/lib
creating gctest
make AR_FLAGS= CC_FOR_BUILD= CFLAGS=-g -O0 CXXFLAGS=-g -O0
CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET= INSTALL=/usr/bin/install -c
INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c
INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=
LIBCFLAGS_FOR_TARGET= MAKE=make MAKEINFO=/bin/sh /opt/gcc/missing --run
makeinfo PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=
RUNTEST= RUNTESTFLAGS= exec_prefix=/usr/local infodir=/usr/local/info
libdir=/usr/local/lib prefix=/usr/local tooldir=AR=ar AS=as CC=gcc
CXX=g++ LD=ld LIBCFLAGS= NM= PICFLAG= RANLIB=ranlib DESTDIR=
check-TESTS
make[2]: Entering directory `/opt/gcc/build/gc'
Segfault at 0x11fc04248
Unexpected bus error or segmentation fault
/bin/sh: line 1: 18963 Aborted LD_LIBRARY_PATH=../../gcc
${dir}$tst
FAIL: gctest
===
1 of 1 tests failed
===
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/opt/gcc/build/gc'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/opt/gcc/build/gc'
make: *** [check-recursive] Error 1
[EMAIL PROTECTED] gc]# LD_LIBRARY_PATH=.libs/ gdb .libs/gctest
GNU gdb Red Hat Linux
[Bug c/20760] cast to variable-length array type combined with switch statement gives segv
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-05 20:50 --- I'd like to get rid of the use of SAVE_EXPR for VLA sizes in C, but there may well be a smaller local fix for this bug. -- What|Removed |Added OtherBugsDependingO||16989 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 20:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20760
[Bug target/19370] .size directive not emitted for mips-linux
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:05 --- fixed quite a while ago. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19370
[Bug target/11787] always call memcpy for block move in mips16
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:23 --- The point of mips16 is smaller code, why would you expect inline memcpy calls at any point? -eric -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11787
[Bug target/11787] always call memcpy for block move in mips16
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com |dot org | Status|WAITING |ASSIGNED Last reconfirmed|2004-01-01 21:19:28 |2005-04-05 21:23:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11787
[Bug ada/18659] [4.0/4.1 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)
--- Additional Comments From laurent at guerby dot net 2005-04-05 21:23 --- Fails on sparc-linux as well. Any resolution on this now that the release is near? With PR18819 these are the cause of the x86 ACATS regressions (3.4 was ACATS failure free on x86). -- What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:26 --- Richard, I think we should probably close this one unless we actually get a chip part that has this failing :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309
[Bug target/18034] GCC 3.4.2/GNAT bootstrap problem
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:35 --- Since I don't have a 6.2 box (and neither does Richard afaik), I'm not certain there's anything we can do about this. You'll either need to debug the differences on your platform between this and 6.5 or something else. Sorry. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18034
[Bug target/19658] fail to build gcc 3.4.3 on IRIX6.5
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:36 --- No response. Cleaning up old prs. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19658
[Bug bootstrap/20155] [4.0/4.1 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-05 21:41 --- Switched component to bootstrap. -- What|Removed |Added Component|libgcj |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug libgcj/20775] Crash in libgcj.so on linux alpha
--- Additional Comments From mckinlay at redhat dot com 2005-04-05 21:46 --- Is this is a Multi-processor machine? Does the crash always occur 100% in the same place or is it intermittent? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20775
[Bug fortran/20774] [3.4 Regression] [g77 only] Debug information in .o (from FORTRAN) points to temporary file under certain circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 22:15 --- Confirmed, only a 3.4 regression as 4.0.0's fortran compiler, gfortran, does not currently support -fno- automaticly (see PR 20592). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2005-04-05 22:15:26 date|| Summary|Debug information in .o |[3.4 Regression] [g77 only] |(from FORTRAN) points to|Debug information in .o |temporary file under certain|(from FORTRAN) points to |circumstances |temporary file under certain ||circumstances Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20774
[Bug target/20776] New: FE_DOWNWARD testcase results differ in -m32 and -m64. OK or bug?
Might not be a bug even, but I haven't had much luck in finding a definitive
answer. I get different output depending on whether I compile the following
testcase as 32-bit vs 64-bit on linux-ppc64 (gcc-3.4 and gcc-4).
include stdio.h
#include fenv.h
int main()
{
int x=1023, y=1023;
double z;
fesetround(FE_DOWNWARD);
z = (double)(x-y);
printf (z = %e\n, z);
return 0;
}
If I compile this as '-O0 -m32' I get a result of:
z = -0.00e+00
But compiling for 64-bit, '-O0 -m64' I get result of:
z = 0.00e+00
This was noticed by someone testing linux-ppc glibc::logb(1) after having set
the rounding mode to FE_DOWNWARD and getting a -0.0 result (glibc has similar
code as testcase above).
GCC bug vs GLIBC bug vs User Error?
--
Summary: FE_DOWNWARD testcase results differ in -m32 and -m64. OK
or bug?
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20776
[Bug testsuite/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-05 22:30 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
