[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #144 from pault at gcc dot gnu dot org 2007-12-06 08:17 --- (In reply to comment #143) CP2K fails again to compile Joost, It's me again! I had naively thought that all the simple combinations of USE statements were covered in the testsuite. Evidently, I was not just naive but wrong. I fixed it this morning and verified that CP2K is OK. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
tiny typo fix
Hi, While grepping the OpenBSD sourcetree for occurences of a typo I found (beeing - being), I came across one instance in the gcc distribution. Attached is a patch that fixes it, but it is a patch against the OpenBSD cvs repository. It is very minor, but still I hope this is of use to you guys. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ Index: 20011130-2.c === RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/testsuite/gcc.c-torture/compile/20011130-2.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 20011130-2.c --- 20011130-2.c29 Nov 2003 12:37:34 - 1.1.1.1 +++ 20011130-2.c6 Dec 2007 08:49:35 - @@ -1,7 +1,7 @@ /* This testcase caused infinite loop in life info computation after if conversion on IA-64. Conditional register dead for pseudo holding sign-extended k was improperly computed, - resulting in this pseudo beeing live at start of bb if it was + resulting in this pseudo being live at start of bb if it was dead at the end and vice versa; as it was a bb which had edge to itself, this resulted in alternative propagating this basic block forever. */ pgpIECs0sSLXY.pgp Description: PGP signature
[Bug c++/34355] New: ICE: invariant not recomputed when ADDR_EXPR changed with -ftree-parallelize-loops
This testcase fails with g++
--cut here--
typedef double EXPRESS[5];
extern int Terms;
void Parse_Rel_Factor (EXPRESS Express, int *Terms)
{
EXPRESS Local_Express = {5.0, 4.0, 3.0, 2.0, 1.0};
int Local_Terms = 5;
int i;
for (i = (*Terms); i Local_Terms; i++)
Express[i] = 0.0;
Express[i] += Local_Express[i];
}
double Parse_Float ()
{
EXPRESS Express = {1.0, 2.0, 3.0, 4.0, 5.0};
Parse_Rel_Factor (Express, Terms);
}
--cut here--
g++ -O3 -msse2 -ftree-parallelize-loops=4 tt.cpp
tt.cpp: In function âdouble Parse_Float()â:
tt.cpp:18: error: invariant not recomputed when ADDR_EXPR changed
(*Express.105_26)[0];
tt.cpp:18: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Please note, that the same testcase, renamed to __.c compiles OK with 'gcc -O3
-msse2 -ftree-parallelize-loops=4 -S tt.c'. [I guess that due to this, 'c++'
component should be selected.]
Also note, that if 'Express[i] += Local_Express[i];' line is removed, g++
segfaults trying to output diagnostics in:
Program received signal SIGSEGV, Segmentation fault.
0x081165d8 in cp_diagnostic_starter (context=0x8a5e040, diagnostic=0xbf8874b0)
at ../../gcc-svn/trunk/gcc/cp/error.c:2466
/home/uros/gcc-svn/trunk/gcc/cp/error.c:2466:64935:beg:0x81165d8
(gdb) bt
#0 0x081165d8 in cp_diagnostic_starter (context=0x8a5e040,
diagnostic=0xbf8874b0) at ../../gcc-svn/trunk/gcc/cp/error.c:2466
#1 0x082b9249 in diagnostic_report_diagnostic (context=0x8a5e040,
diagnostic=0xbf8874b0) at ../../gcc-svn/trunk/gcc/diagnostic.c:421
#2 0x082b952a in error (gmsgid=0x893c52c invariant not recomputed when
ADDR_EXPR changed) at ../../gcc-svn/trunk/gcc/diagnostic.c:558
#3 0x084b3a51 in verify_expr (tp=0xb7c1c724, walk_subtrees=0xbf887568,
data=0x0) at ../../gcc-svn/trunk/gcc/tree-cfg.c:3191
#4 0x0867544b in walk_tree_1 (tp=0xb7c1c724, func=0x84b2d50 verify_expr,
data=0x0, pset=0x0, lh=0) at ../../gcc-svn/trunk/gcc/tree.c:8376
#5 0x0867557a in walk_tree_1 (tp=0xb7ccfdfc, func=0x84b2d50 verify_expr,
data=0x0, pset=0x0, lh=0) at ../../gcc-svn/trunk/gcc/tree.c:8615
#6 0x0849ff1c in verify_stmts () at ../../gcc-svn/trunk/gcc/tree-cfg.c:4140
#7 0x085fb00f in verify_ssa (check_modified_stmt=1 '\001') at
../../gcc-svn/trunk/gcc/tree-ssa.c:613
#8 0x08411b25 in execute_function_todo (data=0x8) at
../../gcc-svn/trunk/gcc/passes.c:963
#9 0x08411779 in do_per_function (callback=0x8411900 execute_function_todo,
data=0x8) at ../../gcc-svn/trunk/gcc/passes.c:805
#10 0x08411851 in execute_todo (flags=524288) at
../../gcc-svn/trunk/gcc/passes.c:989
#11 0x08411cda in execute_one_pass (pass=0x8a4f860) at
../../gcc-svn/trunk/gcc/passes.c:1081
--
Summary: ICE: invariant not recomputed when ADDR_EXPR changed
with -ftree-parallelize-loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
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=34355
[Bug fortran/34333] if(nan == nan) wrongly returns TRUE, when nan is a parameter
--- Comment #7 from burnus at gcc dot gnu dot org 2007-12-06 09:23 --- Subject: Bug 34333 Author: burnus Date: Thu Dec 6 09:23:00 2007 New Revision: 130644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130644 Log: 2007-12-06 Tobias Burnus [EMAIL PROTECTED] PR fortran/34333 * primary.c (match_boz_constant): Add gfc_notify_std * diagnostics. 2007-12-06 Tobias Burnus [EMAIL PROTECTED] PR fortran/34333 * gfortran.dg/boz_7.f90: New. * gfortran.dg/int_1.f90: Disable -pedantic option. * gfortran.dg/boz_1.f90: Ditto. * gfortran.dg/boz_3.f90: Ditto. * gfortran.dg/pr16433.f: Accomodate for new BOZ warning. * gfortran.dg/ibits.f90: Ditto. * gfortran.dg/unf_io_convert_1.f90: Ditto. * gfortran.dg/unf_io_convert_2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/boz_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/boz_1.f90 trunk/gcc/testsuite/gfortran.dg/boz_3.f90 trunk/gcc/testsuite/gfortran.dg/ibits.f90 trunk/gcc/testsuite/gfortran.dg/int_1.f90 trunk/gcc/testsuite/gfortran.dg/pr16433.f trunk/gcc/testsuite/gfortran.dg/unf_io_convert_1.f90 trunk/gcc/testsuite/gfortran.dg/unf_io_convert_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34333
[Bug c++/34336] [4.2/4.3 Regression] 4.2.2 internal error in stabilize_expr
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-06 09:33 --- Subject: Bug 34336 Author: jakub Date: Thu Dec 6 09:33:26 2007 New Revision: 130645 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130645 Log: PR c++/34336 * tree.c (stabilize_call, stabilize_init): Do nothing if processing_template_decl. * g++.dg/template/new8.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/new8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34336
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #15 from jakub at gcc dot gnu dot org 2007-12-06 10:06 --- Subject: Bug 34005 Author: jakub Date: Thu Dec 6 10:06:38 2007 New Revision: 130647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130647 Log: 2007-12-06 Zdenek Dvorak [EMAIL PROTECTED] Dorit Nuzman [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR tree-optimization/34005 * tree-gimple.c (is_gimple_formal_tmp_rhs): Add a case for COND_EXPR. * gimplify.c (gimplify_ctx): Add a new member allow_rhs_cond_expr. (gimplify_pure_cond_expr): New function. (generic_expr_could_trap_p): New function. (gimplify_cond_expr): Call gimplify_pure_cond_expr. (force_gimple_operand): Initialize new field allow_rhs_cond_expr. 2007-12-06 Martin Michlmayr [EMAIL PROTECTED] Dorit Nuzman [EMAIL PROTECTED] PR tree-optimization/34005 * gcc.dg/vect/pr34005.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr34005.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-gimple.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug c++/34336] [4.2 Regression] 4.2.2 internal error in stabilize_expr
--- Comment #8 from jakub at gcc dot gnu dot org 2007-12-06 09:54 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.2 4.3.0 |4.2.2 Summary|[4.2/4.3 Regression] 4.2.2 |[4.2 Regression] 4.2.2 |internal error in |internal error in |stabilize_expr |stabilize_expr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34336
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #16 from jakub at gcc dot gnu dot org 2007-12-06 10:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34355] ICE: invariant not recomputed when ADDR_EXPR changed with -ftree-parallelize-loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-06 10:37 --- Confirmed. eliminate_local_variables_1 changes Express[0] to (*Express.96_73)[0] without re-computing invariantness. With the structure of eliminate_local_variables_stmt (it seems to operate on non-gimple), it looks like it would require a second walk over the stmt to recompute invariantness (or to make sure to do this at gimplification time). Or to walk depth-first. I'll leave that to Zdenek to figure out. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-06 10:37:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34355
[Bug fortran/34342] BOZ extensions not diagnosed as such with -std=f95
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-06 12:15 --- Created an attachment (id=14702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14702action=view) Draft patch for further BOZ diagnostic The attached patch shows how one could implement: - Error for initializing non-integers in DATA statements (invalid Fortran 2003/95) - Print a warning for real(BOZ), dble(BOZ) etc., which are interpreted different then required by Fortran 2003. Missing: - REAL(BOZ) does not print a warning, only REAL(BOZ, kind) works as for the former, gfc_simplify_real is not called. I need to find out what route is taken for REAL() and INT(). - The boz == true needs to be falsed as some point, esp. after int(BOZ) it shall not be present. (In principle, the warning could be replaced by a TRANSFER, which might be enough to get Fortran 2003 BOZ working.) Also missing: a) As soon as there is Fortran 2003 BOZ support, one needs to modify match_boz_constant. Currently, it gives with -std=f* an error if a BOZ is used outside DATA; in Fortran 2003 this is allowed in REAL() etc., but not elsewhere. b) One may think of treating real_variable = BOZ as real_variable = real(BOZ) instead of as real_variable = int(BOZ) But one has to think of how to handle real_variable = 0.0 + BOZ real_variable = 0 + BOZ etc. in this case. I think other compilers tread only lhs = BOZ as real BOZ and lhs = expression(BOZ) as integer BOZ, but one should do some tests to confirm this and state clearly in http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html how BOZ are treated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34342
[Bug ada/34356] New: Can't bootstrap ADA on mainline
Tried to bootstrap using gnat-gpl-2007-i686-gnu-linux-libc2.3-bin.tar.gz as host compiler. Error is : /var/pisi/gcc-4.3_pre20071206-31/work/gcc-4.3-20071206/build-default-i686-pc-linux-gnu/./prev-gcc/xgcc -B/var/pisi/gcc-4.3_pre20071206-31/work/gcc-4.3-20071206/build-default-i686-pc-linux-gnu/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -march=i686 -ftree-vectorize -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-generate -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada ../../gcc/ada/s-carun8.adb -o ada/s-carun8.o ../../gcc/ada/a-except.adb: In function 'Ada.Exceptions.Raise_From_Controlled_Operation': ../../gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 +===GNAT BUG DETECTED==+ | 4.3.0 20071206 [trunk revision 130641] (i686-pc-linux-gnu) GCC error:| | verify_flow_info failed | | Error detected around ../../gcc/ada/a-except.adb:1305| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 -- Summary: Can't bootstrap ADA on mainline Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34356
[Bug ada/34356] Can't bootstrap ADA on mainline
--- Comment #1 from ismail at pardus dot org dot tr 2007-12-06 12:23 --- Dup of bug #32581, stupid me. *** This bug has been marked as a duplicate of 32581 *** -- ismail at pardus dot org dot tr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34356
[Bug bootstrap/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20
--- Comment #3 from ismail at pardus dot org dot tr 2007-12-06 12:23 --- *** Bug 34356 has been marked as a duplicate of this bug. *** -- ismail at pardus dot org dot tr changed: What|Removed |Added CC||ismail at pardus dot org dot ||tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
[Bug c++/34357] New: internal compiler error: in layout_type, at stor-layout.c:1864
The following code fragment (generated during a delta debugging session)
produces an ICE:
==
template typename struct iterator_traits {
template typename ForwardIterator , iterator_traits ForwardIterator
__attribute__ __visibility__ ( default )
==
$ g++-trunk -v -c ice.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/tmp --program-suffix=-trunk
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20071206 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/tmp/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1plus -quiet -v -D_GNU_SOURCE
ice.cpp -quiet -dumpbase ice.cpp -mtune=generic -auxbase ice -version -o
/tmp/cch00yQX.s
ignoring nonexistent directory
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/i686-pc-linux-gnu
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/backward
/usr/local/include
/tmp/include
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/include
/tmp/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.3.0 20071206 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20071206 (experimental), GMP version
4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 905119d664de60becf7da68735772a8c
ice.cpp:2: warning: __visibility__ attribute ignored on non-class types
ice.cpp:2: internal compiler error: in layout_type, at stor-layout.c:1864
Please submit a full bug report,
--
Summary: internal compiler error: in layout_type, at stor-
layout.c:1864
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
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=34357
[Bug c++/34357] internal compiler error: in layout_type, at stor-layout.c:1864
--- Comment #1 from gcc at abeckmann dot de 2007-12-06 13:02 --- Also present in gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) == internal compiler error: in layout_type, at stor-layout.c:1851 Not found in gcc version 4.1.3 20071019 (prerelease) (Debian 4.1.2-17) gcc version 4.0.4 20060904 (prerelease) (Debian 4.0.3-7) gcc version 3.4.6 (Debian 3.4.6-6) gcc version 3.3.6 (Debian 1:3.3.6-15) (reports (different kinds of) syntax errors in all these versions -- gcc at abeckmann dot de changed: What|Removed |Added Known to fail||4.3.0 4.2.3 Known to work||4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34357
[Bug c++/34357] [4.2/4.3 Regression] internal compiler error: in layout_type, at stor-layout.c:1864
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-06 13:16 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2007-12-06 13:16:30 date|| Summary|internal compiler error: in |[4.2/4.3 Regression] |layout_type, at stor- |internal compiler error: in |layout.c:1864 |layout_type, at stor- ||layout.c:1864 Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34357
[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #13 from jakub at gcc dot gnu dot org 2007-12-06 13:25 --- Subject: Bug 20983 Author: jakub Date: Thu Dec 6 13:25:37 2007 New Revision: 130650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130650 Log: PR middle-end/20983 * tree-ssa-ccp.c (optimize_stdarg_builtin): New function. (execute_fold_all_builtins): Call it for BUILT_IN_VA_START, BUILT_IN_VA_COPY and BUILT_IN_VA_END. * target.h (struct ggc_target): Add expand_builtin_va_start hook. * target-def.h (TARGET_EXPAND_BUILTIN_VA_START): Define. (TARGET_INITIALIZER): Add it. * builtins.c (expand_builtin_va_start): Use targetm.expand_builtin_va_start hook instead of EXPAND_BUILTIN_VA_START macro. * alpha/alpha.c (alpha_va_start): Made static. (override_options): Clear targetm.expand_builtin_va_start if TARGET_UNICOSMK. (TARGET_EXPAND_BUILTIN_VA_START): Define. * alpha/unicosmk.h (EXPAND_BUILTIN_VA_START): Remove. * alpha/alpha.h (EXPAND_BUILTIN_VA_START): Remove. * alpha/alpha-protos.h (alpha_va_start): Remove prototype. * xtensa/xtensa.h (EXPAND_BUILTIN_VA_START): Remove. * xtensa/xtensa.c (TARGET_EXPAND_BUILTIN_VA_START): Define. (xtensa_va_start): Made static. * xtensa/xtensa-protos.h (xtensa_va_start): Remove prototype. * pa/pa-protos.h (hppa_va_start): Remove prototype. * pa/pa.h (EXPAND_BUILTIN_VA_START): Remove. * pa/pa.c (hppa_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * frv/frv.c (frv_expand_builtin_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * frv/frv-protos.h (frv_expand_builtin_va_start): Remove prototype. * frv/frv.h (EXPAND_BUILTIN_VA_START): Remove. * i386/i386.c (override_options): Clear targetm.expand_builtin_va_start if -m32 or 64-bit MS ABI. (ix86_va_start): Made static. (TARGET_EXPAND_BUILTIN_VA_START): Define. * i386/i386.h (EXPAND_BUILTIN_VA_START): Remove. * i386/i386-protos.h (ix86_va_start, ix86_va_arg): Remove prototypes. * iq2000/iq2000-protos.h (iq2000_va_start): Remove prototype. * iq2000/iq2000.h (EXPAND_BUILTIN_VA_START): Remove. * iq2000/iq2000.c (iq2000_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * rs6000/rs6000-protos.h (rs6000_va_start): Remove prototype. * rs6000/rs6000.c (rs6000_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. (rs6000_override_options): Clear targetm.expand_builtin_va_start if DEFAULT_ABI != ABI_V4. * rs6000/rs6000.h (EXPAND_BUILTIN_VA_START): Remove. * spu/spu.c (spu_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * spu/spu.h (EXPAND_BUILTIN_VA_START): Remove. * spu/spu-protos.h spu_va_start): Remove prototype. * stormy16/stormy16.h (EXPAND_BUILTIN_VA_START): Remove. * stormy16/stormy16-protos.h (xstormy16_expand_builtin_va_start): Remove prototype. * stormy16/stormy16.c (xstormy16_expand_builtin_va_start): Made static. (TARGET_EXPAND_BUILTIN_VA_START): Define. * s390/s390-protos.h (s390_va_start): Remove prototype. * s390/s390.c (s390_va_start): Made static. (TARGET_EXPAND_BUILTIN_VA_START): Define. * s390/s390.h (EXPAND_BUILTIN_VA_START): Remove. * mn10300/mn10300.h (EXPAND_BUILTIN_VA_START): Remove. * mn10300/mn10300-protos.h (mn10300_va_start): Remove prototype. * mn10300/mn10300.c (mn10300_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * arc/arc.c (arc_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * arc/arc.h (EXPAND_BUILTIN_VA_START): Remove. * arc/arc-protos.h (arc_va_start): Remove prototype. * mt/mt-protos.h (mt_va_start): Remove prototype. * sparc/sparc.c (sparc_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * sparc/sparc-protos.h (sparc_va_start): Remove prototype. * sparc/sparc.h (EXPAND_BUILTIN_VA_START): Remove. * sh/sh.c (sh_va_start): Made static, add prototype. (TARGET_EXPAND_BUILTIN_VA_START): Define. * sh/sh-protos.h (sh_va_start): Remove prototype. * sh/sh.h (EXPAND_BUILTIN_VA_START): Remove. * mips/mips-protos.h (mips_va_start): Remove prototype. * mips/mips.h (EXPAND_BUILTIN_VA_START): Remove. * mips/mips.c (mips_va_start): Made static. (TARGET_EXPAND_BUILTIN_VA_START): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/alpha/alpha-protos.h trunk/gcc/config/alpha/alpha.c
[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #14 from jakub at gcc dot gnu dot org 2007-12-06 13:28 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug ada/34358] New: Dynamic library created in Object_Dir instead of Library_Dir in *-darwin*
Hi, I've found the following bug in GNAT when building dynamic libraries using project files: Ada spec (p.ads) package P is procedure Dummy; end P; Ada body (p.adb) package body P is --- -- Dummy -- --- procedure Dummy is begin null; end Dummy; end P; Project file (lib_project.gpr) === project Lib_Project is for Source_Files use (p.ads, p.adb); for Library_Name use my_lib; for Library_Dir use ./libs; for Object_Dir use ./objects; for Library_Kind use relocatable; end Lib_Project; Command: = % gnatmake -p -P lib_project.gpr % ls objects libs Expected behavior: == % gnatmake -p -P lib_project.gpr object directory /Volumes/Stock/Dev/gnat_bug_report/./objects created library directory /Volumes/Stock/Dev/gnat_bug_report/./libs created gcc -c -fPIC -I- -gnatA /Volumes/Stock/Dev/gnat_bug_report/p.adb building relocatable library for project lib_project /Volumes/Stock/Dev/gcc-4.3_trunk/bin/gcc -dynamiclib -o /Volumes/Stock/Dev/gnat_bug_report/libs/libmy_lib.dylib -L/Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -fPIC -L/Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -lgnat-4.3 -Wl,-flat_namespace -shared-libgcc /Volumes/Stock/Dev/gnat_bug_report/objects/p.o /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib//libgnat-4.3.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [The warning issued by the linker here is another independant bug (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572)] % ls objects libs libs: libmy_lib.dylib p.ali objects: p.ali p.o Actual behavior: % gnatmake -p -P lib_project.gpr object directory /Volumes/Stock/Dev/gnat_bug_report/./objects created library directory /Volumes/Stock/Dev/gnat_bug_report/./libs created gcc -c -fPIC -I- -gnatA /Volumes/Stock/Dev/gnat_bug_report/p.adb building relocatable library for project lib_project /Volumes/Stock/Dev/gcc-4.3_trunk/bin/gcc -dynamiclib -o libmy_lib.dylib -L/Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -fPIC -L/Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -lgnat-4.3 -Wl,-flat_namespace -shared-libgcc /Volumes/Stock/Dev/gnat_bug_report/objects/p.o /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /Volumes/Stock/Dev/gcc-4.3_trunk/lib/gcc/i686-apple-darwin8/4.3.0/adalib//libgnat-4.3.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) % ls objects libs libs: p.ali objects: libmy_lib.dylib p.ali p.o The library file libmy_lib.dylib is created in the object directory. This causes a problem if we want to link against this library... The attached patch fixes this problem. Here is my system configuration: * the exact version of GCC, as shown by gcc -v; Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local Thread model: posix gcc version 4.3.0 20071206 (experimental) (GCC) * the system type (uname -a); Darwin x..xx 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 * the options when GCC was configured/built; ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local -- Summary: Dynamic library created in Object_Dir instead of Library_Dir in *-darwin* Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bechir dot zalila at gmail dot com GCC build triplet: i686-apple-darwin8 GCC host triplet: i686-apple-darwin8 GCC target triplet: i686-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34358
[Bug ada/34358] Dynamic library created in Object_Dir instead of Library_Dir in *-darwin*
--- Comment #1 from bechir dot zalila at gmail dot com 2007-12-06 13:48 --- Created an attachment (id=14703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14703action=view) Patch file that solves the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34358
[Bug fortran/34345] gfortran compiles SLATEC library, but the executable fails
--- Comment #4 from dir at lanl dot gov 2007-12-06 14:56 --- I have several programs (f77 and f90) that do this and their intent is clear - just put the bit patterns into to words as requested - no data conversion - no range checking. BOZ seems to have been created for this purpose, but the committee seems the have lost track of why programs need specific bit patterns and how they are used. How about adding something like a -fhex enhancement that does this ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34345
[Bug fortran/34359] New: ICE in December 6 version of gfortran when compiling a file with two routines that contain INCLUDE statements
I downloaded the December 6 version of gfortran from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz and attempted to compile the following file: SUBROUTINE f1 INCLUDE anything END SUBROUTINE f1 SUBROUTINE f2 INCLUDE anything END SUBROUTINE f2 The INCLUDE file can contain anything. I got the following message: f.f90:1: internal compiler error: in change_file, at fortran/scanner.c:322 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in December 6 version of gfortran when compiling a file with two routines that contain INCLUDE statements Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34359
[Bug ada/34360] New: typo gcc/ada/Makefile.in for GNU/kFreeBSD
Perusing the file I see around line 879: TOOLS_TARGET_PAIRS = \ mlib-tgt.adbmlib-tgt-linux.adb \ indepsw.adbindepsw-gnu.adb I think this should be mlib-tgt-specific.adbmlib-tgt-linux.adb instead like for all other targets. The file mlib-tgt.adb is no longer target-specific. -- Summary: typo gcc/ada/Makefile.in for GNU/kFreeBSD Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34360
[Bug ada/34361] New: Incorrect comment at top of mlib-tgt.adb
The comments at the top of mlib-tgt.adb are now wrong; subprograms are not dummies anymore, they are stubs that call their counterparts in MLIB.Tgt.Specific. The comment is misleading. -- Summary: Incorrect comment at top of mlib-tgt.adb Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34361
[Bug c++/34362] New: Segmentation fault while using array of character pointers.
The following code produces segmentation fault at runtime.
-CODE-
#include stdio.h
#include string.h
main()
{
char * strArray[2];
printf(Enter 1:);
scanf(%s,strArray[0]);
printf(Enter 2:);
scanf(%s,strArray[1]);
}
However the following code does not,
-CODE-
#include stdio.h
#include string.h
main()
{
char * strArray[2];
printf(Enter 1:);
scanf(%s,strArray[0]);
printf(Enter 2:);
scanf(%s,strArray[1]);
int x = 0;
}
-ERROR
Enter 1:hello
15669: symbol=__cxa_finalize; lookup in file=./stringEx1.s
15669: symbol=__cxa_finalize; lookup in file=/usr/lib/libstdc++.so.6
15669: symbol=__cxa_finalize; lookup in
file=/lib/tls/i686/cmov/libm.so.6
15669: symbol=__cxa_finalize; lookup in file=/lib/libgcc_s.so.1
15669: symbol=__cxa_finalize; lookup in
file=/lib/tls/i686/cmov/libc.so.6
Segmentation fault
--
Summary: Segmentation fault while using array of character
pointers.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevekoe at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34362
[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-12-06 16:54 --- WONTFIX on the branches, adjusting target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.3 4.2.2 Target Milestone|4.1.3 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug c++/34362] Segmentation fault while using array of character pointers.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-06 17:06 --- scanf does not initiale the pointers. You just have some random pointer values passed to scanf. -- 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=34362
[Bug fortran/34359] ICE in December 6 version of gfortran when compiling a file with two routines that contain INCLUDE statements
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-06 17:13 --- Known, but not yet fixed. See: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00260.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-06 17:13:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34359
[Bug other/32263] Document the required versions of glibc and binutils
--- Comment #7 from appfault at hotmail dot com 2007-12-06 17:26 --- Instead of trying to lock down the full and complete list of acceptable glibs, you could at least give a hint as to what GCC was using at the time a given release did work. A known working version list seems very simple to maintain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug c/34363] New: Aliasing failure during tree fre
Simple test case:
unsigned n;
void foo (unsigned *p)
{
n = 4;
*p = 0;
if (n != 0)
abort ();
}
main ()
{
foo (n);
return 0;
}
Tested cross-compiling for MIPS, also verified that x86 also has the same
problem.
attached dump from the fre pass.
basically n.0_4 should not be assigned the value of 4, since *p can alias
it.
;; Function foo (foo)
Created value VH.0 for p_3
exp_gen[0] := { }
tmp_gen[0] := { p_3 (VH.0) }
avail_out[0] := { p_3 (VH.0) }
exp_gen[2] := { }
tmp_gen[2] := { }
avail_out[2] := { p_3 (VH.0) }
exp_gen[3] := { }
tmp_gen[3] := { }
avail_out[3] := { p_3 (VH.0) }
exp_gen[4] := { }
tmp_gen[4] := { }
avail_out[4] := { p_3 (VH.0) }
exp_gen[1] := { }
tmp_gen[1] := { }
avail_out[1] := { }
Replaced n with 4 in n.0_4 = n;
foo (p)
{
unsigned int n.0;
bb 2:
n = 4;
*p_3 = 0;
n.0_4 = 4;*
if (n.0_4 != 0) goto L0; else goto L1;
L0:;
abort ();
L1:;
return;
}
--
Summary: Aliasing failure during tree fre
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidu at mips dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34363
[Bug c/29172] --combine can't handle #pragma once
--- Comment #7 from tromey at gcc dot gnu dot org 2007-12-06 18:56 --- Subject: Bug 29172 Author: tromey Date: Thu Dec 6 18:56:26 2007 New Revision: 130656 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130656 Log: gcc PR c/29172: * c-opts.c (c_common_parse_file): Call cpp_clear_file_cache. libcpp PR c/29172: * internal.h (struct cpp_reader) file_hash_entries: Changed type. file_hash_entries_allocated, file_hash_entries_used: Removed. * files.c (FILE_HASH_POOL_SIZE): New macro. (struct file_hash_entry_pool): New. (destroy_all_cpp_files): New function. (allocate_file_hash_entries): Allocate a file_hash_entry_pool. (new_file_hash_entry): Update. (free_file_hash_entries): New function. (_cpp_cleanup_files): Call free_file_hash_entries and destroy_all_cpp_files. (cpp_clear_file_cache): New function. * include/cpplib.h (cpp_clear_file_cache): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/libcpp/ChangeLog trunk/libcpp/files.c trunk/libcpp/include/cpplib.h trunk/libcpp/internal.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
[Bug c/29172] --combine can't handle #pragma once
--- Comment #8 from tromey at gcc dot gnu dot org 2007-12-06 18:58 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-29 23:26:05 |2007-12-06 19:03:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug fortran/34345] gfortran compiles SLATEC library, but the executable fails
--- Comment #5 from kargl at gcc dot gnu dot org 2007-12-06 19:13 --- (In reply to comment #4) I have several programs (f77 and f90) that do this and their intent is clear - just put the bit patterns into to words as requested - no data conversion - no range checking. Which is of course nonstandard. The F95 standard is quite clear on where a BOZ can appear and that a BOZ is an integer. BOZ seems to have been created for this purpose, Maybe. BOZ doesn't appear in my copy of the F77 standard (on a quick scan), and I don't have a copy of F90 to check. However, F95 is quite clear on BOZ but the committee seems the have lost track of why programs need specific bit patterns and how they are used. See the TRANSFER intrinsic. I think J3 recognized the problems with specify a bit pattern. J3 also appears to have recognized the limitations on TRANSFER because they have allowed BOZ to appear in REAL, INT, DBLE, and COMPLX. Unfortunately, J3 didn't define what this means! How about adding something like a -fhex enhancement that does this ? This is a very nontrivial option to add, and it opens the door to (mis)feature creep of a extension. What happens with subroutine add(y, x) real x, y do i = 1, 1000 x = y + Z'deadbeef' + 42 end do end subroutine Is Z'deadbeef' an integer or a real? If one uses the normal rules of Fortran and using BOZ for short, a compiler can do either x = (y + BOZ) + 42 ! Conversion of BOZ to real??? or x = y + (BOZ + 42) ! Conversion of BOZ to integer??? Note, the latter form allows the compiler to constant fold and hoist (BOZ + 42) out of the loop; thereby saving 1 million additions. I suppose one could argue that the scanner can recognize that a BOZ is present in the expression and then promote it to the highest type. The above would then become x = y + REAL(BOZ, kind(y)) + 42 or, perhaps, x = y + REAL(BOZ, kind(x)) + 42 ! x is double prec and y is REAL? because the programmer obviously meant the BOZ should have the same kind as the LHS. In the end, one would probably want x = y + REAL(BOZ, max(kind(x), kind(y))) + 42 to avoid possible loss of precision in the BOZ. Here's a more complicated example module fun interface whoops module procedure p_int module procedure p_real end interface contains subroutine p_int(x) integer, intent(in) :: x print '(I0)', x end subroutine p_int subroutine p_real(x) real, intent(in) :: x print '(ES12.4)', x end subroutine p_real end module fun use fun call whoops(Z'deadbeef') ! Is this an integer or real??? end program I suppose that one can argue that gfortran can restrict BOZ to the simplest form of an initialization expression. real, parameter :: x = z'deadbeef'! Allowed real bit pattern real, parameter :: y = z'deadbeef'+1. ! Not allowed, BOZ in a RHS expression This argument, IMHO, boils down to I don't care what gfortan does as along as it does what I want. Now for the fun. How is z'deadbeef' interpreted on big and little endian hardware? Before you scoff, realize that gfortran has to convert the BOZ into something that MPFR can digest. This means that gfortran has do something like z'deadbeef' -- -0X3.ABC123p2 where the number following p is the exponent in base 16. I've, of course, not discussed whether the exponent portion of z'deadbeef' is a biased or unbiased exponent. I guess gfortran will assume that it is biased. Now, what integer value are you subtracting to get the 2 that follows the p? There's even more fun if the BOZ is too small. What does gfortran do with z'dead'? Is this z'dead' or z'dead' or is this literally only 2 bytes and the other 2 bytes are whatever is currently in memory? Having spent a considerable amount of time thinking about ways to fix, I can assure you that it isn't a simple matter of just adding -fhex. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34345
[Bug c++/34364] New: [4.1/4.2/4.3] class is not known as as a class-type anymore after dynamic_cast
The following code fails to compile
struct A {
virtual ~A() {}; //make A polymorphic
};
struct B: public A
{
template typename T2
class C
{
public:
static void f (A a)
{
dynamic_castB( a ).g();
}
};
void g () {}
};
... and issues the following Error message:
test.cpp: In static member function 'static void B::UpdateT2::g(A)':
test.cpp:21: error: request for member 'g' in 'dynamic_castB(a)', which is
of non-class type 'B'
On the other hand, it works if either C is not a template or B is a template.
this fails for 4.1.3, 4.2.2 and 4.3.0
--
Summary: [4.1/4.2/4.3] class is not known as as a class-type
anymore after dynamic_cast
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34364
[Bug c++/34365] New: Diagnostic mistakenly characterizes function as being overloaded
When asked to compile the following code:
template typename void f();
void g() { fint; }
G++ opines:
error: statement cannot resolve address of overloaded function
However, f is not overloaded. (The standard says: When two or more different
declarations are specified for a single name in the same scope, that name is
said to be overloaded.)
PS. As for the validity of the code: while I personally really wouldn't know
whether it is valid, I should for completeness at least mention that it is
accepted by Comeau.
--
Summary: Diagnostic mistakenly characterizes function as being
overloaded
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34365
[Bug bootstrap/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20
--- Comment #5 from ismail at pardus dot org dot tr 2007-12-06 20:56 --- a-except.adb ali.adb cstand.adb einfo.adb exp_attr.adb exp_dbug.adb osint.adb par.adb prepcomp.adb restrict.adb rtsfind.adb s-os_lib.adb scn.adb sem_attr.adb sem_util.adb sprint.adb switch-c.adb targparm.adb files crashes if -fprofile-generate is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
[Bug ada/34366] New: Legal program rejected, various anonymous access-to-subprogram types, Ada 2005
package test2 is pragma elaborate_body; type T is record F1: access function(x: integer) return T; F2: access function(x: T) return integer; --?? F3: access function(x: T) return T; --?? F4: access function(x: integer) return access T; --?? F5: access function(x: access T) return integer; F6: access function(x: access T) return access T; F7: access function(x: T) return access T;--?? F8: access function(x: access T) return T; end record; end test2; package body test2 is R: aliased T; function F1 (x: integer) return T is begin return R; end; function F2 (x: T) return integer is begin return 0; end; function F3 (x: T) return T is begin return R; end; function F4 (x: integer) return access T is begin return R'access; end; function F5 (x: access T) return integer is begin return 0; end; function F6 (x: access T) return access T is begin return R'access; end; function F7 (x: T) return access Tis begin return R'access; end; function F8 (x: access T) return Tis begin return R; end; begin R.F1 := F1'Access; R.F2 := F2'Access; R.F3 := F3'Access; R.F4 := F4'Access; R.F5 := F5'Access; R.F6 := F6'Access; R.F7 := F7'Access; R.F8 := F8'Access; end test2; In both GCC 4.1.2 and 4.2.2 the symptoms are the same: gnatmake -gnat05 test2 gcc-4.1 -c -gnat05 test2.adb test2.adb:17:15: expected type access to type derived from Standard.Integer defined at test2.ads:6 test2.adb:17:15: found type access to f2 defined at line 17 test2.adb:18:15: expected type access to type derived from t defined at test2.ads:7 test2.adb:18:15: found type access to f3 defined at line 18 test2.adb:19:15: found type access to f4 defined at line 19 test2.adb:20:15: expected an access type with designated type derived from Standard.Integer defined at test2.ads:4 test2.adb:20:15: found an access type with designated type F5 defined at line 10 test2.adb:21:15: expected an access type with designated type derived from access to t defined at test2.ads:4 test2.adb:21:15: found an access type with designated type F6 defined at line 11 test2.adb:22:15: found type access to f7 defined at line 22 test2.adb:23:15: expected an access type with designated type derived from t defined at test2.ads:4 test2.adb:23:15: found an access type with designated type F8 defined at line 13 test2.ads:6:32: type declaration cannot refer to itself test2.ads:7:32: type declaration cannot refer to itself test2.ads:8:55: type declaration cannot refer to itself test2.ads:11:32: type declaration cannot refer to itself test2.ads:11:49: type declaration cannot refer to itself gnatmake: test2.adb compilation error Note how the assignment to R.F1 gives no error message. In assignments with error messages, the compiler incorrectly expects the right-hand side of the assignment to have an access type to the return value of the function; not the access-to-subprogram type. -- Summary: Legal program rejected, various anonymous access-to- subprogram types, Ada 2005 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34366
[Bug ada/34367] New: Bug box, Assert_Failure exp_ch4.adb:4550 on legal Ada 2005 program
package pak1 is type T1 is tagged limited null record; type T2 is limited interface; function f1 (x2: access T2'Class) return integer; type T3 is new T1 and T2 with record x1: integer := f1 (T3'Access); -- line 8, column 28 is the tick end record; end pak1; gnatmake -gnat05 pak1 gcc-4.1 -c -gnat05 pak1.ads +===GNAT BUG DETECTED==+ | 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) (x86_64-pc-linux-gnu) | | Assert_Failure exp_ch4.adb:4501 | | Error detected at pak1.ads:8:28 | gcc -c -gnat05 pak1.ads +===GNAT BUG DETECTED==+ | 4.2.2 (i686-unknown-linux-gnu) Assert_Failure exp_ch4.adb:4550 | | Error detected at pak1.ads:8:28 | -- Summary: Bug box, Assert_Failure exp_ch4.adb:4550 on legal Ada 2005 program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34367
[Bug ada/34368] New: Bug box, Assert_Failure einfo.adb:2031 on legal Ada 2005 program (limited with)
package pak2 is package pak3 is end pak3; end pak2; limited with pak2; package pak1 is -- line 2 pragma elaborate_body; end pak1; with pak2; package body pak1 is end pak1; gnatmake -gnat05 pak1 gcc-4.1 -c -gnat05 pak1.adb +===GNAT BUG DETECTED==+ | 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:2012| | Error detected at pak1.ads:2:9 | +===GNAT BUG DETECTED==+ | 4.2.2 (i686-unknown-linux-gnu) Assert_Failure einfo.adb:2031 | | Error detected at pak1.ads:2:9 | -- Summary: Bug box, Assert_Failure einfo.adb:2031 on legal Ada 2005 program (limited with) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34368
[Bug fortran/34345] gfortran compiles SLATEC library, but the executable fails
--- Comment #6 from burnus at gcc dot gnu dot org 2007-12-06 21:34 --- but the committee seems the have lost track of why programs need specific bit patterns and how they are used. See the TRANSFER intrinsic. I think J3 recognized the problems with specify a bit pattern. J3 also appears to have recognized the limitations on TRANSFER because they have allowed BOZ to appear in REAL, INT, DBLE, and COMPLX. Unfortunately, J3 didn't define what this means! Well, if they had specified what it means, having different hard ware (e.g. decimal numbers in silicon) would have been more complicated. How about adding something like a -fhex enhancement that does this ? This is a very nontrivial option to add, and it opens the door to (mis)feature creep of a extension. Well, to allow BOZ in DATA statements (for non-integers) and for real r = 'b0'z it is relatively easy. What happens with x = y + Z'deadbeef' + 42 Is Z'deadbeef' an integer or a real? With my patch, it is an integer, only in variable = boz boz might be a real/complex bit patter. As soon as you have expressions on the right-hand side, the boz is regarded as integer. I find this clear than all the boz + integer is integer+integer but boz + 1.0 is real+real convention some compilers have. call whoops(Z'deadbeef') ! Is this an integer or real??? With my patch it is an integer (no assignment and not in a DATA statement). I suppose that one can argue that gfortran can restrict BOZ to the simplest form of an initialization expression. real, parameter :: x = z'deadbeef'! Allowed real bit pattern real, parameter :: y = z'deadbeef'+1. ! Not allowed, BOZ in a RHS expression This plus BOZ in DATA statements is what my patch (to be submitted in a moment) does. (Well, it does not reject the second version but regards it as integer pattern.) The patch also gives some better diagnostic with -std=f95 and -Wsurprising. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-06 21:34:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34345
[Bug c++/34365] Diagnostic mistakenly characterizes function as being overloaded
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-06 21:46 --- *** This bug has been marked as a duplicate of 11407 *** -- 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=34365
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-12-06 21:46 --- *** Bug 34365 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug java/34369] New: java.net.URI.relativize(URI) method returns incorrect results
The method java.net.URI.relativize(URI) returns incorrect results for a couple
of cases when compared to implementations from IBM Java or Sun Java.
This problem affects directly the debugging process of C projects on Eclipse.
Whenever someone is debugging a project whose part of its name is the
name of another project on the workspace, Eclipse doesn't find the correct path
for the project source files. For instance, if we have a project named a and
another project named aa and we try to debug a file on aa, Eclipse will
match the path for the file on aa with the path to the project a and will
not find the file as it doesn't exist on project a.
The method documentaion at
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html#relativize(java.net.URI)
says:
The relativization of the given URI against this URI is computed as follows:
1. If either this URI or the given URI are opaque, or if the scheme and
authority components of the two URIs are not identical, or if the path of this
URI is not a prefix of the path of the given URI, then the given URI is
returned.
2. Otherwise a new relative hierarchical URI is constructed with query and
fragment components taken from the given URI and with a path component computed
by removing this URI's path from the beginning of the given URI's path.
The test for if the path of this URI is not a prefix of the path of the given
URI then the given URI is returned in libjava/classpath/java/net/URI.java does
not appear correct:
public URI relativize(URI uri)
{
if (isOpaque() || uri.isOpaque())
return uri;
if (scheme == null uri.getScheme() != null)
return uri;
if (scheme != null !(scheme.equals(uri.getScheme(
return uri;
if (rawAuthority == null uri.getRawAuthority() != null)
return uri;
if (rawAuthority != null !(rawAuthority.equals(uri.getRawAuthority(
return uri;
if (!(uri.getRawPath().startsWith(rawPath))) this test
return uri;
In some cases I would expect uri.getRawPath().startsWith(rawPath) to return
true since with a simple string character sequence test of startsWith() such as
with the string
file:/home/eclipse/runtime-New_configuration/simple
would be a prefix of
file:/home/eclipse/runtime-New_configuration/simple_spu/simple_spu.c
even though simple and simple_spu are technically different paths. This I think
is where the other VM implementations must be doing it correctly as they likely
examine components of a path as opposed to just a string prefix check.
A second problem is that when the code drops through to
return new URI(null, null,
uri.getRawPath().substring(rawPath.length()),
uri.getRawQuery(), uri.getRawFragment());
the substring() method may end up returning a leading '/' on the path in some
cases which all the other JVMs do not.
The proposed solution is to create a new path with '/' appended to this.rawPath
for the given base URI we are checking for. We would have to check that it
isn't
already the last character. Example:
file:/home/eclipse/runtime-New_configuration/simple
becomes
file:/home/eclipse/runtime-New_configuration/simple/
which is stored in basePath and then the
if (!(uri.getRawPath().startsWith(basePath)))
should end up returning uri since it doesn't have basePath as prefix when it is
for the path
file:/home/eclipse/runtime-New_configuration/simple_spu/simple_spu.c for
example.
In addition, to correct avoiding returning a leading '/' a one line change is
done to uri.getRawPath().substring(rawPath.length()) to instead get the length
of the basePath string as it should always conclude with a '/'.
A testcase is supplied to provide examples of the results from various calls to
the URI.relativize() method. Here is the results from the unpatched, failing
code as it is right now:
[EMAIL PROTECTED] ~]$ java Test
_spu/simple_spu.c
eclipse
/runtime-New_configuration/simple
Here are the results after applying the patch and re-running the testcase:
[EMAIL PROTECTED] ~]$ java Test
file:/home/eclipse/runtime-New_configuration/simple_spu/simple_spu.c
eclipse
runtime-New_configuration/simple
The above output is consistent with that provided by executing the testcase
using IBM Java 5, Sun Java 5 and IBM Java 1.4.2.
--
Summary: java.net.URI.relativize(URI) method returns incorrect
results
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lnx1138 at us dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug java/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #1 from lnx1138 at us dot ibm dot com 2007-12-06 22:12 --- Created an attachment (id=14704) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14704action=view) testcase Sample java code providing two examples where URI.relativize() method is not consistent with other JVM implementations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug libfortran/34370] New: file positioning after nonadvancing i/o
... should add a record marker. F 2003, 9.2.3.1: If a nonadvancing output statement leaves a file positioned 1 within a current record and no further output statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement is executed for it, the effect is as if the output statement were the corresponding advancing output statement. $ cat advance.f90 program main open(95, form=formatted) write (95, '(A)', advance=no) 'a' backspace 95 end program main $ gfortran advance.f90 $ ./a.out $ cat fort.95 a$ -- Summary: file positioning after nonadvancing i/o Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34370
[Bug java/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #2 from lnx1138 at us dot ibm dot com 2007-12-06 22:15 --- Created an attachment (id=14705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14705action=view) gcc-libjava-uri-relativize.patch to fix java.net.URI.relativize(URI) method This patch corrects two issues found in URI.relativize() method in libjava/classpath/java/net/URI.java. It applies from gcc 4.1.2 through latest trunk: * does stricter check for a path match while still using String.startsWith() * excludes leading '/' if necessary for relative path fragment being returned -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug ada/34367] Bug box, Assert_Failure exp_ch4.adb:4550 on legal Ada 2005 program
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-06 23:29 --- Already fixed on trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34367
[Bug ada/34368] Bug box, Assert_Failure einfo.adb:2031 on legal Ada 2005 program (limited with)
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-06 23:30 --- Already fixed on trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34368
[Bug ada/34366] Legal program rejected, various anonymous access-to-subprogram types, Ada 2005
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-06 23:35 --- Confirmed on 4.3.0 20071206 -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-06 23:35:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34366
[Bug middle-end/17736] Optimization for global initialization with trivial constructors
--- Comment #3 from mrs at apple dot com 2007-12-06 23:46 --- radr://2961456 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17736
[Bug c/34363] Aliasing failure during tree fre
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-07 00:14 --- This worked in 4.3.0 20071127. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34363
[Bug ada/34366] Legal program rejected, various anonymous access-to-subprogram types, Ada 2005
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-07 02:54 --- Confirmed on 4.3.0 20071206 -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-06 23:35:41 |2007-12-07 02:54:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34366
[Bug libfortran/34370] file positioning after nonadvancing i/o
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-07 04:32 --- Thomas, this should be straightforward. Do you want to work this along with PR 34323 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34370
[Bug tree-optimization/34371] New: [4.3 Regression] verify_stmts failed (incorrect sharing of tree nodes)
with current trunk: (sid)2354:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize funnelweb-dump.c funnelweb-dump.c: In function 'centerln': funnelweb-dump.c:4: error: incorrect sharing of tree nodes prologue_after_cost_adjust.25_40 = (unsigned int) D.1554_7; (unsigned int) D.1554_7; funnelweb-dump.c:4: internal compiler error: verify_stmts failed This didn't happen with 20071116. -- Summary: [4.3 Regression] verify_stmts failed (incorrect sharing of tree nodes) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34371
[Bug tree-optimization/34371] [4.3 Regression] verify_stmts failed (incorrect sharing of tree nodes)
--- Comment #1 from tbm at cyrius dot com 2007-12-07 04:45 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
void centerln (int width, int ch, char *s)
{
unsigned int sidebar;
int i;
char linet1[1000];
char linet2[100];
sidebar = (width - __builtin_strlen (s)) / 2;
for (i = 0; i sidebar; i++)
linet2[i] = ch;
__builtin_strcpy (linet1, linet2);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34371
