[Bug fortran/30520] Conflics checking of VOLATILE attribute needs improvement
--- Comment #3 from burnus at gcc dot gnu dot org 2007-01-31 09:18 --- Subject: Bug 30520 Author: burnus Date: Wed Jan 31 09:18:33 2007 New Revision: 121379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121379 Log: fortran/ 2007-01-31 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30520 * interface.c (compare_actual_formal): Check conformance between actual and VOLATILE dummy arguments. * symbol.c (gfc_add_volatile): Allow setting of VOLATILE multiple times in different scopes. * decl.c (gfc_match_volatile): Search symbol in host association. testsuite/ 2007-01-31 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30520 * gfortran.dg/volatile8.f90: New argument conformance test. * gfortran.dg/volatile9.f90: New scope test. Added: trunk/gcc/testsuite/gfortran.dg/volatile8.f90 trunk/gcc/testsuite/gfortran.dg/volatile9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30520
[Bug fortran/30520] Conflics checking of VOLATILE attribute needs improvement
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-31 09:20 --- FIXED in gcc 4.3 (note: VOLATILE is not in 4.2). See PR 30522 for the missing parts. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30520
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-31 09:26 --- Dear All, This is yet another derived type association problem in trans-types.c(gfc_get_derived_type). If you insert a "use foo_type_mod" in module foo_mod, the problem goes away. I believe the INTENT(OUT) changes the order in which the different references to type foo_type are visited; I believe one of them, most likely in the interface, is not being registered in the namespace. I will investigate further - it's a matter o perspiration now, rather than inspiration. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #7 from patchapp at dberlin dot org 2007-01-31 09:45 --- Subject: Bug number PR28943 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02582.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug fortran/20896] [4.2 and 4.1 only] ambiguous interface not detected
--- Comment #7 from burnus at gcc dot gnu dot org 2007-01-31 09:55 --- > > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00145.html > Do we have consensus yet on this? > The standard is not exactly straight forward interpret. I'm not 100% sure. The standard is indeed not very clear about it. My feeling is that the standard forbids some of the things on the basis that the compiler is not required to check those, but I should study the patch and the standard again. With the patch the following is not ambiguous: + SUBROUTINE s2(p2) + interface + function p2 () + real p2 + end + end interface + END + SUBROUTINE s1(p1) + external p1 + END This is based on the following: the first one is a function (well, that's obvious) and the second one is a subroutine. But is this indeed clear? Without IMPLICIT NONE the second could be equally well a real function, or do I miss something subtle? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at net-b dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-31 10:24 --- Subject: Bug 27588 Author: burnus Date: Wed Jan 31 10:23:53 2007 New Revision: 121401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121401 Log: (This part was missing in the r118852 / Wed Nov 15 10:13:16 2006 check in) 2007-01-31 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27588 * gfortran.dg/char_bounds_check_fail_1.f90: Add test. Added: trunk/gcc/testsuite/gfortran.dg/char_bounds_check_fail_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug java/30641] gcj corrupted double-linked list (glibc detected)
--- Comment #2 from msubs at philips dot org dot uk 2007-01-31 10:27 --- Created an attachment (id=12984) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12984&action=view) Valgrind log Hi Tom, Thanks. Attached is a valgrind log. jc1 invoked as below: valgrind /home/matt/cross-tools/libexec/gcc/i386-mingw32msvc/4.3.0/jc1 -v /tmp/MyApp-dist/MyApp-client.jar -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase MyApp-client.jar -mtune=i386 -auxbase MyApp-client -g1 -version -fjni -fbootclasspath=/home/matt/projects/java4/MyApp/lib/client/win32/swt.jar:/home/matt/projects/java4/MyApp/build/:/home/matt/projects/java4/org.eclipse.swt/swt.jar:/home/matt/projects/java4/MyApp/lib/commons-logging.jar:/home/matt/projects/java4/MyApp/lib/icu4j-3_6.jar:/home/matt/projects/java4/MyApp/lib/jbpm-3.1.1.jar:/home/matt/projects/java4/MyApp/lib/log4j-1.2.8.jar:/home/matt/projects/java4/MyApp/lib/org.eclipse.core.commands_3.2.0.I20060605-1400.jar:/home/matt/projects/java4/MyApp/lib/org.eclipse.core.runtime_3.2.0.v20060603.jar:/home/matt/projects/java4/MyApp/lib/org.eclipse.equinox.common_3.2.0.v20060603.jar:/home/matt/projects/java4/MyApp/lib/org.eclipse.jface_3.2.1.M20060908-1000.jar:/home/matt/projects/java4/MyApp/lib/org.eclipse.osgi_3.2.1.R32x_v20060919.jar:/home/matt/projects/java4/MyApp/lib/resources.jar:/home/matt/projects/java4/MyCompany/lib/activation.jar:/home/matt/projects/java4/MyCompany/lib/datafile.jar:/home/matt/projects/java4/MyCompany/lib/jTDS2.jar:/home/matt/projects/java4/MyCompany/lib/jargs.jar:/home/matt/projects/java4/MyCompany/lib/jcommon-0.9.7.jar:/home/matt/projects/java4/MyCompany/lib/jconn2.jar:/home/matt/projects/java4/MyCompany/lib/junit.jar:/home/matt/projects/java4/MyCompany/lib/jxl.jar:/home/matt/projects/java4/MyCompany/lib/mail.jar:/home/matt/projects/java4/MyCompany/lib/postgresql-8.2dev-503.jdbc3.jar:/home/matt/projects/java4/MyCompany/lib/servlet.jar:/home/matt/projects/java4/MyCompany/lib/xercesImpl.jar:/home/matt/projects/java4/MyCompany/lib/xml-apis.jar:/home/matt/projects/java4/MyCompany/lib/xml-writer.jar:/local/jboss/client/jbossall-client.jar:/local/jboss/client/ejb3-persistence.jar:/local/jboss/client/jboss-annotations-ejb3.jar:/home/matt/cross-tools/share/java/libgcj-4.3.0.jar -faux-classpath MyApp-client.zip -o MyApp-client.s 2>&1 | tee /tmp/MyApp-dist/valgrind.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30641
[Bug gcov-profile/30650] New: [Regression 4.3] ICE with -fprofile-use
This is with gcc-Version 4.3.0 20070131 on x86_64-unknown-linux-gnu. Using the Polyhedron tests, four tests fail with the -fprofile-use option, cf. http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/#rt The tests are available from: http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html I did: gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops -ftree-vectorize -msse3 -O3 -o aermod aermod.f90 ./aermod gfortran -fprofile-use -march=opteron -ffast-math -funroll-loops -ftree-vectorize -msse3 -O3 aermod.f90 The latter crashes with test.f90: In function 'setidg': test.f90:48679: internal compiler error: Floating point exception If the *.gc* file(s) don't exist, no error occures. This regression occurs between 2007-01-27-r121231 and 2007-01-30-r121332. Program received signal SIGFPE, Arithmetic exception. 0x0076c316 in stringop_block_profile (stmt=0x2b59f9ca67d0, expected_align=0x7fffb3a2ed70, expected_size=0x7fffb3a2ed68) at /projects/tob/gcc/gcc/value-prof.c:1440 1440 size = ((histogram->hvalue.counters[0] (gdb) bt #0 0x0076c316 in stringop_block_profile (stmt=0x2b59f9ca67d0, expected_align=0x7fffb3a2ed70, expected_size=0x7fffb3a2ed68) at /projects/tob/gcc/gcc/value-prof.c:1440 #1 0x004c4f97 in expand_builtin_memset (arglist=, target=0x2b59f70c7400, mode=VOIDmode, orig_exp=0x2b59f9ca67d0) at /projects/tob/gcc/gcc/builtins.c:3739 #2 0x004c86db in expand_builtin (exp=0x2b59f9ca67d0, target=0x2b59f70c7400, subtarget=0x0, mode=VOIDmode, ignore=1) at /projects/tob/gcc/gcc/builtins.c:6228 #3 0x00534bb8 in expand_expr_real_1 (exp=0x2b59f9ca67d0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /projects/tob/gcc/gcc/expr.c:7724 #4 0x0053a3e3 in expand_expr_real (exp=0x2b59f9ca67d0, target=0x2b59f70c7400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /projects/tob/gcc/gcc/expr.c:6746 #5 0x00642049 in expand_expr_stmt (exp=0x2b59fa3e8540) at /projects/tob/gcc/gcc/expr.h:501 #6 0x008ed6b5 in expand_gimple_basic_block (bb=0x2b59fa526000) at /projects/tob/gcc/gcc/cfgexpand.c:1540 #7 0x008ee42e in tree_expand_cfg () at /projects/tob/gcc/gcc/cfgexpand.c:1810 -- Summary: [Regression 4.3] ICE with -fprofile-use Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30650
[Bug debug/30651] New: GCC 4.2.0-20061226 fails to compile Valgrind 3.2.2
For Valgrind 3.2.2 compilation with ./configure CC='gcc42' CXX='g++42'; make fails with error message memcheck_x86_linux-mc_main.o(.debug_info+0xa62d): undefined reference to `hacky_auxmaps' The compilation with gcc-3.3.6 works fine, so it's not the problem with Valgrind. GCC 4.2.0 was configured with options /root/sources/gcc-4.2-20061226/configure --prefix=/usr/local/gcc42 --program-suffix=42 --with-gnu-as --with-gnu-ld --enable-threads --enable-tls --with-cpu=pentium-m --enable-__cxa-atexit --enable-version-specific-runtime-libs --enable-languages=c,c++ --disable-libada --enable-checking=release --disable-nls --with-long-double-128 -- Summary: GCC 4.2.0-20061226 fails to compile Valgrind 3.2.2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i686-slackware-linux-gnu GCC host triplet: i686-slackware-linux-gnu GCC target triplet: i686-slackware-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30651
[Bug debug/30651] GCC 4.2.0-20061226 fails to compile Valgrind 3.2.2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-31 12:28 --- This is a dup of PR27657. *** This bug has been marked as a duplicate of 27657 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30651
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-31 12:28 --- *** Bug 30651 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aanisimov at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug target/30652] New: SSE expansion is missing for isinf() and other fpclassify functions
Following testcase does not compile to inlined asm when -mfpmath=sse is used:
--cut here--
int test(double a)
{
return isinf(a + 2.0);
}
--cut here--
gcc -O2 -msse3 -mfpmath=sse -fomit-frame-pointer:
test:
movsd .LC0, %xmm0
addsd 4(%esp), %xmm0
movsd %xmm0, 4(%esp)
jmp isinf
An "isinf2" expander in config/i386/i386.md should be enhanced to expand
isinf() function to use SSE1/SSE2 FP bitops for -mfmpath=sse.
--
Summary: SSE expansion is missing for isinf() and other
fpclassify functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ssemmx
Severity: enhancement
Priority: P3
Component: target
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=30652
[Bug gcov-profile/30650] [Regression 4.3] ICE with -fprofile-use
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-31 12:48 ---
Confirmed. I'm confused by the code anyways:
size = ((histogram->hvalue.counters[0]
+ histogram->hvalue.counters[0] / 2)
/ histogram->hvalue.counters[0]);
according to the source counter[0] is supposed to be the sum of the sizes and
counters[1] the call count. Also all of this profiling stuff needs better
commenting. Like
#define GCOV_COUNTER_AVERAGE6 /* The most common difference between
consecutive values of expression. */
#define GCOV_COUNTER_IOR7 /* The most common difference between
consecutive values of expression. */
and
case HIST_TYPE_AVERAGE:
hist->n_counters = 3;
break;
(which should be 2?) as
void
__gcov_average_profiler (gcov_type *counters, gcov_type value)
{
counters[0] += value;
counters[1] ++;
}
suggests.
So the code in question should probably read
if (!histogram
|| histogram->hvalue.counters[1] == 0)
*expected_size = -1;
else
{
gcov_type size;
size = ((histogram->hvalue.counters[0]
+ histogram->hvalue.counters[0] / 2)
/ histogram->hvalue.counters[1]);
but defering to Honza who wrote all this code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-31 12:48:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30650
[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-31 12:57 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-31 12:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652
[Bug other/30653] New: Memory leak in translate_name
In function translate_name, in file gcc-4.1.1\gcc\prefix.c, at line 204, variable key is allocated a block of memory, however this memory is never returned to the system, which will casue memory leak. Suggest add "free(key);" around line 227 just inside the for loop from line 193. -- Summary: Memory leak in translate_name Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wuhui1973 at 21cn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30653
[Bug other/30653] Memory leak in translate_name
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-31 13:13 --- It's using alloca which returns memory that is automatically freed when the calling function returns. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30653
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-31 13:38 ---
Only C++ warns for the testcase, we get C to warn as well if we remove
/* For &x[y], return x+y */
if (TREE_CODE (arg) == ARRAY_REF)
{
tree op0 = TREE_OPERAND (arg, 0);
if (!c_mark_addressable (op0))
return error_mark_node;
return build_binary_op (PLUS_EXPR,
(TREE_CODE (TREE_TYPE (op0)) == ARRAY_TYPE
? array_to_pointer_conversion (op0)
: op0),
TREE_OPERAND (arg, 1), 1);
}
from c-typeck.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
-- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug fortran/30654] New: Segmentation fault -O2 of file with deep nested loops
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) gfortran -O2 -g Test is attached. -- Summary: Segmentation fault -O2 of file with deep nested loops Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vladimir dot sysoev at gmail dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-31 13:44 --- Note that replacing D.2440_4 = base_1 + 2048B; with D.2440_4 = &emergency_buffer[0][2048]; as done by ccp1 is not valid as the new index (2048) is outside of the value range of TYPE_DOMAIN there. This may eventually confuse VRP and aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops
--- Comment #1 from vladimir dot sysoev at gmail dot com 2007-01-31 13:45 --- Created an attachment (id=12985) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12985&action=view) Sample is cutted from big spec test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops
--- Comment #2 from vladimir dot sysoev at gmail dot com 2007-01-31 13:45 --- Looks like #28592 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #4 from christian dot bruel at st dot com 2007-01-31 13:47 --- Hereattached a patch to fix a few problems: 1) Rounding to nearest must be infinity if the "infinitely precise result has a magniture at least 2 exp Emax (2-2exp-p)" (ansi 754/1985 sect 4.1). The implementation for addsf3 and adddf3 returned a NaN. 2) Infinity in divsf3.S was not set (case of 1.0/0.0). 2007-01-29 Christian Bruel <[EMAIL PROTECTED]> * config/sh/IEEE-754/m3/adddf3.S: Fix inf mantissa. * config/sh/IEEE-754/m3/addsf3.S: Likewise. * config/sh/IEEE-754/m3/divsf3.S: Intialize xff00 label. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #5 from christian dot bruel at st dot com 2007-01-31 13:50 --- Created an attachment (id=12986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12986&action=view) fixes the nearest to infinity and divide by 0 bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-01-31 13:55 --- Actually fold-const.c:try_move_mult_to_index does this transformation. I'll fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #6 from christian dot bruel at st dot com 2007-01-31 13:56 --- (From update of attachment 12986) (note: this diff was made from the wrong direction. (-) shows the newest version. sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug fortran/30655] New: Undue out-of-bounds warning
gfortran should not report an out-of-bounds access on the following code: $ cat a.f90 integer i(12), j j = -1 i(0:j) = 42 end $ gfortran a.f90 a.f90:3.4: i(0:j) = 42 1 Warning: Array reference at (1) is out of bounds Compiling with -fbounds-check and running it doesn't error, which means the -fbounds-check code is generated fine. But, somewhere, the front-end is over-zealous (it doesn't know about stride). I thought I had that fixed at some point... -- Summary: Undue out-of-bounds warning Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30655
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-31 14:18 --- Created an attachment (id=12987) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12987&action=view) This fixes the PR This is just now regtesting - I am pretty sure that it is OK. It will take a day or two to feed into the loop. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops
--- Comment #3 from dominiq at lps dot ens dot fr 2007-01-31 14:36 --- The variable 'ii1' does not seem initialized before line 34 where it is used. On my tests with the original code I got the output: 144454401.0 without optimization. With optimization, gfortran 4.3.0 20070126 gives 1.00, xlf 1454401.000, and g95 a segmentation fault. If I add a line: ii1=1. before jj1=1. all the compilers give 14401.* with or without optimization. This was detected with -fbounds-check, it could also have been detected with "implicit none" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-31 14:55 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #39 from ghazi at gcc dot gnu dot org 2007-01-31 15:06 --- Subject: Bug 29335 Author: ghazi Date: Wed Jan 31 15:06:19 2007 New Revision: 121423 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121423 Log: PR middle-end/29335 * builtins.c (fold_builtin_sqrt): Use MPFR for constant args. testsuite: * gcc.dg/torture/builtin-math-2.c: Add sqrt cases. * gcc.dg/torture/builtin-math-3.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #20 from mtrudel at gmx dot ch 2007-01-31 16:19 --- In case it helps; I use this configuration on my 32bit Linux box to configure: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/gcc --build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++,java --enable-libgcj --with-gnu-as --with-gnu-ld --disable-nls --disable-debug --disable-checking --enable-threads=posix --disable-win32-registry --with-gmp=/home/Marco/Desktop/gmp-out --with-mpfr=/home/Marco/Desktop/mpfr-out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-31 17:01 --- This is just a random guess, but do you have this patch (gcc/java): 2007-01-29 Andrew Haley <[EMAIL PROTECTED]> * class.c (add_method_1): Mark fndecl as external unless we are compiling it into this object file. This may affect the latest problem here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug fortran/30656] ICE with -ftrapv
--- Comment #1 from schnetter at aei dot mpg dot de 2007-01-31 17:02 --- Created an attachment (id=12988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12988&action=view) Failing source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug fortran/30656] ICE with -ftrapv
--- Comment #2 from schnetter at aei dot mpg dot de 2007-01-31 17:02 --- Created an attachment (id=12989) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12989&action=view) Used module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug fortran/30656] New: ICE with -ftrapv
With gfortran version GNU Fortran 95 (GCC) 4.3.0 20070125 (experimental) when compiling the attached source files with $ ~/gcc/bin/gfortran -ftrapv -c dissipation_coeff.f90 Dissipation_4_3_min_err_coeff.f90 I receive the error message gfortran: Internal error: Illegal instruction (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -ftrapv Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: i386-apple-darwin8.8.1 GCC host triplet: i386-apple-darwin8.8.1 GCC target triplet: i386-apple-darwin8.8.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-31 17:11 --- Subject: Bug 30606 Author: tromey Date: Wed Jan 31 17:11:11 2007 New Revision: 121425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121425 Log: PR libgcj/30606: * configure, include/config.h.in: Rebuilt. * configure.ac: Check for magic_t in magic.h. * java/net/natVMURLConnection.cc: Use HAVE_MAGIC_T. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/include/config.h.in trunk/libjava/java/net/natVMURLConnection.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #27 from aesok at gcc dot gnu dot org 2007-01-31 17:24 --- Subject: Bug 19087 Author: aesok Date: Wed Jan 31 17:23:49 2007 New Revision: 121426 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121426 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #11 from janis at gcc dot gnu dot org 2007-01-31 17:34 --- The other DejaGnu procs that are wrapped in the GCC testsuite, like dg-test, are used within the .exp files, not within tests; that's why dg-error and dg-warning are different. Developers are familiar with test directives but most have probably never looked inside the .exp files. Ben Elliston is also a DejaGnu maintainer, and we've talked about fixing things like this in DejaGnu and moving GCC to a new version. One problem is that it's difficult to move GCC to newer tools; another is that in this case, the behavior isn't compatible if we keep the same names. Perhaps we should back up and design new test directives for diagnostics from scratch, starting by coming up with a list of requirements for them. That might be easier to do on the wiki. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #28 from aesok at gcc dot gnu dot org 2007-01-31 17:35 --- Subject: Bug 19087 Author: aesok Date: Wed Jan 31 17:35:01 2007 New Revision: 121428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121428 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug fortran/30656] ICE with -ftrapv
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-31 17:35 --- We're endlessly folding something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-01-31 18:08 --- This is a bug in the program (as noted in comment #3). We warn about this with the right options: $ gfortran -O2 -Wall tr30654.f tr30654.f:35.17: iii1=ii1+i1-1 1 Error: Symbol 'ii1' at (1) has no IMPLICIT type $ vi tr30654.f $ gfortran -O2 -Wall tr30654.f tr30654.f: In function 'MAIN__': tr30654.f:35: warning: 'ii1' is used uninitialized in this function $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-maintainer-mode --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070127 (experimental) Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30654
[Bug c++/30657] New: template class derived from template class does not access base class' members
Listing 1 compiles fine:
class smallclass {
public:
int uu;
smallclass(void) : uu(1) { }
};
class largeclass : public smallclass {
public:
int *uup;
void test(void) { uup = &(smallclass::uu); }
};
int main () {
largeclass a;
a.test();
}
Listing 2 fails:
template class smallclass {
public:
E uu;
smallclass(void) : uu(1) { }
}; // class smallclass
template class largeclass : public smallclass {
public:
E *uup;
void test(void) { uup = &(uu); }
};
int main () {
largeclass a;
a.test();
}
The error on compile on both gcc-4.0.1 and 3.4.1 is:
'uu' was not declared in this scope or `uu' undeclared
If one tries to fix it like this:
void test(void) { uup = &(smallclass::uu); }
the error on both gcc-4.0.1 and 3.4.1 becomes:
error: cannot convert 'int smallclass::*' to 'int*' in assignment
All code compiles fine on:
- Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86 (Visual Studio 2005)
- cxx (v6.5 su Tru64/alpha)
- aCC (vA.5.55 per HP-UX/Itanium)
- intel cc 9.0
- gcc 3.2 and 3.3
- Comeau C++ 4.3.3
--
Summary: template class derived from template class does not
access base class' members
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot greppi at tiscali dot it
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30657
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-31 18:10 --- (In reply to comment #11) > The other DejaGnu procs that are wrapped in the GCC testsuite, like dg-test, > are used within the .exp files, not within tests; that's why dg-error and > dg-warning are different. Developers are familiar with test directives but > most have probably never looked inside the .exp files. I don't think that they need to, except for the people responsible for maintaining the testsuite. I have no idea of Tcl and the behaviour of expect is still a mistery (even with --verbose --verbose --verbose --verbose --verbose --debug --debug --debug). I wished I'd never had to look at it. Some people just assume a behaviour and their tests are useless against a warning changed to an error, interactions between the messages in different lines, duplicated messages. Other people try to workaround these issues, so they end up making difficult to fix the problem. The question is: do we want dg-gcc-warning dg-gcc-error obligatory from now on? Or we prefer to fix the testcases and wrap dg-warning and dg-error? I believe doing nothing was already discarded. > Ben Elliston is also a DejaGnu maintainer, and we've talked about fixing > things > like this in DejaGnu and moving GCC to a new version. One problem is that > it's > difficult to move GCC to newer tools; another is that in this case, the > behavior isn't compatible if we keep the same names. The behaviour is not compatible because some testcases are broken (the fewer from what I have seen), others are using workarounds (that we could try to workaround, for example matching "error" any number of times for dg-error), and others are using dg-warning to match messages from the compiler that are not warnings nor errors. However, I don't see how we can avoid to have our own directives (either wrapped dg-* or either custom dg-gcc-*), since the difference between them depend on GCC, so it will make dejagnu not useful for other projects. We even have differences within GCC: gfortran uses its own style for diagnostics, that is why my patch has to restore the original directives for gfortran.exp! > Perhaps we should back up and design new test directives for diagnostics from > scratch, starting by coming up with a list of requirements for them. That > might be easier to do on the wiki. I agree with this but... can't we do something meanwhile? Isn't my patch an improvement over the current situation? I am afraid there is no much interest in fixing this. And as time goes by, the testsuite grows fast and changing the current situation gets more impossible. :-( I just want to know whether keep working in the patch and fixing testcases or just forget about it and wait for the new directives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/30655] Undue out-of-bounds warning
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-31 18:13 --- Really? This is fine: integer i(12), j i(0:-1) = 42 end In your test case, the compiler has a hard time detecting the value of j, and the lower bound would be incorrect if j >=1. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30655
[Bug c++/30657] template class derived from template class does not access base class' members
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-31 18:16 --- And all the other compilers are incorrect as uu is not dependent so it is looked up during parsing and not during instatintation. The correct fix for this is to make it dependent like &(this->uu) instead. Please read: http://gcc.gnu.org/gcc-3.4/changes.html -- 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=30657
[Bug target/28183] [4.0/4.1/4.2/4.3 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
--- Comment #6 from zippel at linux-m68k dot org 2007-01-31 18:20 --- This bug can be closed, it's really a bug in binutils triggered by some inline assembly in cln. Here is a bit more info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug target/28183] [4.0/4.1/4.2/4.3 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-31 18:27 --- Marking as invalid as requested. -- 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=28183
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #13 from janis at gcc dot gnu dot org 2007-01-31 18:34 --- Manuel, I think your patch is a good idea but I'd rather have it add new directives with different names so that developers won't be confused by having different behavior, especially if Fortran tests need something different. I tried changing your patch to add dg-gcc-error and dg-gcc-warning instead of wrapping dg-error and dg-warning and it worked, at least as a starting point. The proposal to get additional requirements was meant to be something that could happen quickly; I'm sure Gaby and Joseph have ideas about what they'd like to see, and we might as well incorporate those now, or at least leave room for extending new directives to handle more functionality. I'd like to use new directives for new tests that need them, quickly convert the existing tests that use ugly workarounds, and gradually move other tests. New tests should use the new directives, but with explicit help telling developers how to use the new ones instead of the old ones. Manuel, I've been busy with other things lately but please let me know what kinds of tests are giving you problems and I'll help look into them. Thanks for doing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #14 from joseph at codesourcery dot com 2007-01-31 19:11 --- Subject: Re: DejaGNU does not distinguish between errors and warnings On Wed, 31 Jan 2007, manu at gcc dot gnu dot org wrote: > However, I don't see how we can avoid to have our own directives (either > wrapped dg-* or either custom dg-gcc-*), since the difference between them > depend on GCC, so it will make dejagnu not useful for other projects. We even > have differences within GCC: gfortran uses its own style for diagnostics, that > is why my patch has to restore the original directives for gfortran.exp! The answer to that is that DejaGnu should provide hooks that testsuites can use to classify diagnostics. Then GCC would provide such hooks saying what's a warning or error, gfortran.exp would provide different hooks, and without hooks from a testsuite DejaGnu could stay compatible with the old behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/30658] New: Optionally, generate .mod files with the interface for files containing only procedures
Currently, there the interface of procedure calls is only checked if they are use or host associated. It would be useful as error check, if optionally for all procedures which are neither part of a module nor of the program, a .MOD file could be created which contains their interface. Example (put in one or two files, compile together or separately): --- program main real(8) :: number number = run_u() end program main function run_u() implicit none real(4) :: run_u run_u = 42.0 end function run_u --- The Intel compiler supports such an option: -gen-interface -warn interface this creates: run_u_mod.mod and run_u_mod.f90 !COMPILER-GENERATED INTERFACE MODULE: Wed Jan 31 20:46:20 2007 MODULE RUN_U_mod INTERFACE FUNCTION RUN_U RESULT(RUN_U_0) REAL(KIND=4) :: RUN_U_0 END FUNCTION RUN_U END INTERFACE END MODULE RUN_U_mod which are then used. (Actually, ifort remains silent about the problem above. It probably converts the real(4) into a real(8), but does not warn!) Expected: - gfortran has a similar option, which creates a .MOD file - Maybe gfortran should also have another option to create a .f90 file (Don't unify these options; as the .f90 files clutter only the directory.) -- Summary: Optionally, generate .mod files with the interface for files containing only procedures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30658
[Bug fortran/30658] Optionally, generate .mod files with the interface for files containing only procedures
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-31 19:54 --- For completeness, it came up here: http://gcc.gnu.org/ml/fortran/2006-09/msg00381.html It came up again http://gcc.gnu.org/ml/fortran/2007-01/msg00716.html The c.l.fortran thread mentioned there is http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4bdd3181137c0c14/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30658
[Bug c++/30659] New: ICE in undefined template
mrs2 $ ./xgcc -B./ /tmp/t.ii
/tmp/t.ii:1: error: ISO C++ forbids declaration of 'basic_istream' with no type
/tmp/t.ii:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
mrs2 $ cat /tmp/t.ii
extern "C" { extern template basic_istream&
operator>>(basic_istream&, string&);
--
Summary: ICE in undefined template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30659
[Bug c++/30659] ICE in undefined template
--- Comment #1 from mrs at apple dot com 2007-01-31 20:30 --- radr://4958852 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30659
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-31 21:07 --- Created an attachment (id=12990) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12990&action=view) patch for minval and maxval Here's a solution for minval and maxval. I'm not yet sure how to deal with matmul, wether by converting its arguments or by creating kind=1 and kind=2 versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #15 from gdr at cs dot tamu dot edu 2007-01-31 21:15 --- Subject: Re: DejaGNU does not distinguish between errors and warnings "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #11) | > The other DejaGnu procs that are wrapped in the GCC testsuite, like dg-test, | > are used within the .exp files, not within tests; that's why dg-error and | > dg-warning are different. Developers are familiar with test directives but | > most have probably never looked inside the .exp files. | | I don't think that they need to, except for the people responsible for | maintaining the testsuite. GCC maintainers are /supposed/ to be familiar with the testsuite framework, fix the testsuite and add more. Well, that is the theory :-) We should fix the broken testcases. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-01-31 21:29 --- Subject: Bug 30546 Author: dfranke Date: Wed Jan 31 21:29:19 2007 New Revision: 121439 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121439 Log: 2007-01-31 Daniel Franke <[EMAIL PROTECTED]> PR libgomp/30546 * acx.m4 (ACX_PROG_CHECK_VER): Locate a program and check that its version is acceptable. Modified: trunk/config/ChangeLog trunk/config/acx.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-01-31 21:30 --- Subject: Bug 30546 Author: dfranke Date: Wed Jan 31 21:30:16 2007 New Revision: 121440 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121440 Log: 2007-01-31 Daniel Franke <[EMAIL PROTECTED]> PR libgomp/30546 * configure.ac: Add check for makeinfo * Makefile.am: Redefined target libgomp.info, build libgomp.info only if an appropiate version of makeinfo is found. * aclocal.m4: Regenerated. * configure: Regenerated. * Makefile.in: Regenerated. * testsuite/Makefile.in: Regenerated. Modified: trunk/libgomp/ChangeLog trunk/libgomp/Makefile.am trunk/libgomp/Makefile.in trunk/libgomp/aclocal.m4 trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug fortran/30660] New: Allocatable components of a derived type "require" the SAVE attribute.
The attached code draws the following, bogus, error message from the compiler: $ /usr/snp/bin/gfortran -c globals.f90 globals.f90:37.24: TYPE(weight_t) g_winfo ! weights info 1 Error: Object 'g_winfo' at (1) must have the SAVE attribute for default initialization of a component globals.f90:36.21: TYPE(grib_t) g_dest ! output field 1 Error: Object 'g_dest' at (1) must have the SAVE attribute for default initialization of a component It's related to the allocatable components of said types. -- Summary: Allocatable components of a derived type "require" the SAVE attribute. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/30660] Allocatable components of a derived type "require" the SAVE attribute.
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-01-31 21:37 --- I can't attach the source file, so I reproduce it here: MODULE types_m INTEGER,PRIVATE,PARAMETER :: MXLEN = 2024, MXKEYS = 50, MXGRIBFLDS = 1000, MXFIN = 2 TYPE coord_t INTEGER ncord REAL,ALLOCATABLE,DIMENSION(:) :: x, y END TYPE TYPE weight_t INTEGER id CHARACTER(LEN=128) :: fname LOGICAL set, init INTEGER ksec2in(60), ksec2out(60) REAL psec2in(60), psec2out(60) INTEGER wdim INTEGER offset(16) INTEGER,ALLOCATABLE,DIMENSION(:) :: gridpts REAL,ALLOCATABLE,DIMENSION(:,:) :: weights REAL,ALLOCATABLE,DIMENSION(:) :: rotX, rotY, rotAngle LOGICAL rotatedComp END TYPE TYPE grib_t INTEGER ksec0(2), ksec1(64), ksec2(64), ksec3(2), ksec4(64) REAL psec2(512), psec3(3) LOGICAL packed ! if packed then the data are stored in g_work INTEGER npts REAL,DIMENSION(:),ALLOCATABLE :: vdata TYPE(coord_t) coords END TYPE END MODULE MODULE globals_m USE types_m TYPE(grib_t) g_dest ! output field TYPE(weight_t) g_winfo! weights info END MODULE Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/30655] Undue out-of-bounds warning
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-31 22:05
---
Around resolve.c:2518:
if (((compare_bound_int (ar->stride[i], 0) == CMP_GT
|| ar->stride[i] == NULL)
&& compare_bound (AR_START, AR_END) != CMP_GT)
|| (compare_bound_int (ar->stride[i], 0) == CMP_LT
&& compare_bound (AR_START, AR_END) != CMP_LT))
when I wrote that code, I stupidly assumed that compare_bound(...) != CMP_GT
was equivalent to compare_bound(...) == CMP_LT || compare_bound(...) == CMP_EQ,
and it's wrong because there's also CMP_UNKNOWN!
The following trivial patch fixes it (I also create a variable to hold the
comparison of AR_START and AR_END, because we use it multiple times).
Index: resolve.c
===
--- resolve.c (revision 121280)
+++ resolve.c (working copy)
@@ -2499,48 +2499,51 @@
break;
case AR_SECTION:
- if (compare_bound_int (ar->stride[i], 0) == CMP_EQ)
- {
- gfc_error ("Illegal stride of zero at %L", &ar->c_where[i]);
- return FAILURE;
- }
-
+ {
#define AR_START (ar->start[i] ? ar->start[i] : as->lower[i])
#define AR_END (ar->end[i] ? ar->end[i] : as->upper[i])
- if (compare_bound (AR_START, AR_END) == CMP_EQ
- && (compare_bound (AR_START, as->lower[i]) == CMP_LT
- || compare_bound (AR_START, as->upper[i]) == CMP_GT))
- goto bound;
+ comparison comp_start_end = compare_bound (AR_START, AR_END);
- if (((compare_bound_int (ar->stride[i], 0) == CMP_GT
- || ar->stride[i] == NULL)
- && compare_bound (AR_START, AR_END) != CMP_GT)
- || (compare_bound_int (ar->stride[i], 0) == CMP_LT
- && compare_bound (AR_START, AR_END) != CMP_LT))
- {
- if (compare_bound (AR_START, as->lower[i]) == CMP_LT)
- goto bound;
- if (compare_bound (AR_START, as->upper[i]) == CMP_GT)
- goto bound;
- }
+ if (compare_bound_int (ar->stride[i], 0) == CMP_EQ)
+ {
+ gfc_error ("Illegal stride of zero at %L", &ar->c_where[i]);
+ return FAILURE;
+ }
- mpz_init (last_value);
- if (compute_last_value_for_triplet (AR_START, AR_END, ar->stride[i],
- last_value))
- {
- if (compare_bound_mpz_t (as->lower[i], last_value) == CMP_GT
- || compare_bound_mpz_t (as->upper[i], last_value) == CMP_LT)
- {
- mpz_clear (last_value);
+ if (comp_start_end == CMP_EQ
+ && (compare_bound (AR_START, as->lower[i]) == CMP_LT
+ || compare_bound (AR_START, as->upper[i]) == CMP_GT))
+ goto bound;
+
+ if (((compare_bound_int (ar->stride[i], 0) == CMP_GT
+ || ar->stride[i] == NULL)
+&& (comp_start_end == CMP_LT || comp_start_end == CMP_EQ))
+ || (compare_bound_int (ar->stride[i], 0) == CMP_LT
+ && (comp_start_end == CMP_GT || comp_start_end == CMP_EQ)))
+ {
+ if (compare_bound (AR_START, as->lower[i]) == CMP_LT)
goto bound;
- }
- }
- mpz_clear (last_value);
+ if (compare_bound (AR_START, as->upper[i]) == CMP_GT)
+ goto bound;
+ }
+ mpz_init (last_value);
+ if (compute_last_value_for_triplet (AR_START, AR_END, ar->stride[i],
+ last_value))
+ {
+ if (compare_bound_mpz_t (as->lower[i], last_value) == CMP_GT
+ || compare_bound_mpz_t (as->upper[i], last_value) == CMP_LT)
+ {
+ mpz_clear (last_value);
+ goto bound;
+ }
+ }
+mpz_clear (last_value);
+
#undef AR_START
#undef AR_END
-
+ }
break;
default:
--
fxcoudert 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-01-31 22:05:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30655
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #16 from manu at gcc dot gnu dot org 2007-01-31 22:23 --- Created an attachment (id=12991) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12991&action=view) version 2 This is a new version of the patch. It fixes some issues with the previous one that made correct testcases to fail (92 in total). I think "concat" was not appropriate, perhaps it was something else... I still have to investigate the ones that fail with this patch to check that none of them are spurious failures caused by some other error in my patch. Also, I removed ":" from the patterns as a workaround to be able to match "cc1: warnings being treated as errors". Still, the message has to be modified to be "being treated as errors", so those testcases still fail with the current patch. Testsuite framework tests pass with this patch. Around 539 files show failing testcases because of this patch. I can provide the full list if some is interested. Suggestions are welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug java/30641] gcj corrupted double-linked list (glibc detected)
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-31 22:34 --- Thanks. That valgrind trace sure is interesting. Do you have a checking-enabled build? You could look for ENABLE_CHECKING in build/gcc/auto-host.h. I'm trying to narrow down which load in rewrite_reflection_indexes is the buggy one; with checking enabled I think a bad load by VEC_index ought to crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30641
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-31 23:01 --- This is fixed by the following patch: Index: trans-array.c === --- trans-array.c (revision 121280) +++ trans-array.c (working copy) @@ -1280,6 +1280,7 @@ gfc_conv_expr (&se, c->iterator->var); gfc_add_block_to_block (pblock, &se.pre); loopvar = se.expr; + TREE_NO_WARNING(loopvar) = 1; /* Make a temporary, store the current value in that and return it, once the loop is done. */ -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-13 14:03:28 |2007-01-31 23:01:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/30656] ICE with -ftrapv
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-31 23:02 --- Breakpoint 3, fold_binary (code=MINUS_EXPR, type=0xb7c0a2d8, op0=0xb7c72f30, op1=0xb7c717b0) at /home/richard/src/trunk/gcc/fold-const.c:8783 8783 enum tree_code_class kind = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (op0) D.1106 - (int4) n (gdb) call debug_generic_expr (op1) -4 9393return fold_build2 (PLUS_EXPR, type, fold_build2_stat (code=PLUS_EXPR, type=0xb7c0a2d8, op0=0xb7c72f30, op1=0xb7c776c0) at /home/richard/src/trunk/gcc/fold-const.c:12421 12421 tem = fold_binary (code, type, op0, op1); (gdb) call debug_generic_expr (op0) D.1106 - (int4) n (gdb) call debug_generic_expr (op1) --4 ouch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #15 from reichelt at gcc dot gnu dot org 2007-01-31 23:03 --- Also fixed in GCC 4.0.4. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug middle-end/30656] [4.3 Regression] ICE with -ftrapv
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end GCC build triplet|i386-apple-darwin8.8.1 | GCC host triplet|i386-apple-darwin8.8.1 | GCC target triplet|i386-apple-darwin8.8.1 | Keywords||ice-on-valid-code Summary|ICE with -ftrapv|[4.3 Regression] ICE with - ||ftrapv Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-31 23:07 --- Why not create a new i for the inner loop instead of saving it off? Or is: integer :: n, i n = 5 n = sum((/(i,i=1,f())/)) contains function f() integer :: f f = i+1 end valid and well defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-25 19:41:20 |2007-01-31 23:15:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug c++/27722] [4.0 regression] ICE incrementing an array
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-01-31 23:16 --- Seems to be fixed in GCC 4.0.4. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
[Bug c++/28235] [4.0 Regression] ICE with static const member as default parameter in template
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-01-31 23:21 --- This is now a rejects-valid again in GCC 4.0.4 (as in 3.4.0 - 4.0.2). So this bug remains unfixed on the 4.0 branch, but is fixed in GCC 4.1.2. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28235
[Bug middle-end/30656] [4.3 Regression] ICE with -ftrapv
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-31 23:24 ---
negate_expr_p says it can negate -4 (which has the overflow flag set), but
negate_expr refuses to, because of the overflow flag.
We get there from
#69 0x080d1145 in gfc_conv_loop_setup (loop=0xbf9d6b4c)
at /home/richard/src/trunk/gcc/fortran/trans-array.c:3219
3219 tmp = fold_build2 (TRUNC_DIV_EXPR, gfc_array_index_type,
(gdb) list
3214 with start = 0, this simplifies to
3215 last = end / step;
3216 for (i = 0; i<=last; i++){...}; */
3217 tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
3218 loop->to[n], loop->from[n]);
3219 tmp = fold_build2 (TRUNC_DIV_EXPR, gfc_array_index_type,
3220 tmp, info->stride[n]);
3221 loop->to[n] = gfc_evaluate_now (tmp, &loop->pre);
3222 /* Make the loop variable start at 0. */
3223 loop->from[n] = gfc_index_zero_node;
(gdb) call debug_tree (tmp)
unit size
align 32 symtab 0 alias set -1 canonical type 0xb7be02d8 precision 32
min max
pointer_to_this >
arg 0
arg 0
arg 0 >
arg 1
used ignored SI file
/Users/eschnett/Calpha/arrangements/LSUThorns/SummationByParts/src/Dissipation_4_3_min_err_coeff.F90
line 445 size unit size
align 32 context >>
arg 1 constant
invariant public overflow -4>>
which has the overflow flag already set, created from
3217 tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
3218 loop->to[n], loop->from[n]);
(gdb) call debug_generic_expr (loop->to[n])
(int4) (() n + 0x0fffc)
(gdb) call debug_generic_expr (loop->from[n])
D.1106
which we fold in reassociation where we finally end up calling
associate_trees with code == PLUS_EXPR
(gdb) call debug_generic_expr (t1)
(int4) n - D.1106
(gdb) call debug_generic_expr (t2)
0x0fffc
and returning via
1413 return build2 (code, type, fold_convert (type, t1),
1414 fold_convert (type, t2));
will cause (int4)0x0fffc to have the overflow flag set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug middle-end/30656] [4.3 Regression] ICE with -ftrapv
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-31 23:27 --- We can fix the symptom by Index: fold-const.c === *** fold-const.c(revision 121440) --- fold-const.c(working copy) *** fold_negate_expr (tree t) *** 1109,1115 case INTEGER_CST: tem = fold_negate_const (t, type); ! if (!TREE_OVERFLOW (tem) || !TYPE_OVERFLOW_TRAPS (type)) return tem; break; --- 1109,1115 case INTEGER_CST: tem = fold_negate_const (t, type); ! if (TREE_OVERFLOW (tem) == TREE_OVERFLOW (t) || !TYPE_OVERFLOW_TRAPS (type)) return tem; break; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-31 23:27:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30656
[Bug c/24577] diagnostic informative note labelled "error"
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-31 23:38 --- (In reply to comment #0) > > Other informative notes are labeled "note:". Because this is labelled "error", > scripts that scan generated compiler output to count errors get wrong counts. > Ivan, the fix is trivial. In c-decl.c (undeclared_variable), replace the call to "error" with a call to "inform". However, it may require updating testcases and the maintainers may prefer to remove the message altogether. Since this is a minor issue, it is not strange that people prefer to do something else. If you are interested in seeing this fixed, this is a good opportunity to learn how to contribute to GCC, since the patch is trivial, the only difficulty is the whole process, that may seem complex at the beginning. You can find more information in http://gcc.gnu.org/contribute.html and ask any question about contributing in [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions
--- Comment #2 from rth at gcc dot gnu dot org 2007-02-01 00:28 --- The generic implementation, including for SSE, is isgreater (abs(f), FLT_MAX) For isfinite, use islessequal instead. For isnan, one can use isunordered(f, f) For isnormal, it'd be isgreaterequal(abs(f), FLT_MIN) & islessequal(abs(f), FLT_MAX) which is less likely to be friendly to inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652
[Bug c/24577] diagnostic informative note labelled "error"
--- Comment #4 from igodard at pacbell dot net 2007-02-01 01:03 --- My employer does not permit employees to contribute to open source projects due to IP concerns. What's your second choice? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
--- Comment #26 from lopresti at gmail dot com 2007-02-01 02:17 --- I found this PR because I tried calling what() on a bad_alloc, was surprised by what I got, and did a search. This is my perspective as a random end user; make of it what you will. I think "std::bad_alloc" is an improvement. But I was actually expecting what() to provide something human readable and very specific, like "out of memory" or "heap corrupted". In my case, I already know the exception is a std::bad_alloc; I could generate that particular constant string myself... I find it remarkable that this PR is almost two years old. -- lopresti at gmail dot com changed: What|Removed |Added CC||lopresti at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #7 from amylaar at gcc dot gnu dot org 2007-02-01 03:41 --- (In reply to comment #4) > Hereattached a patch to fix a few problems: > > 1) Rounding to nearest must be infinity if the "infinitely precise result has > a > magniture at least 2 exp Emax (2-2exp-p)" (ansi 754/1985 sect 4.1). The > implementation for addsf3 and adddf3 returned a NaN. Not always a NaN, but it's a bug regardless. Good catch. However, this: LOCAL(inf): + mov #0,DBLRL negatively impacts sh3 MA unit scheduling. It might be an idea to align LOCAL(pos_difference_0) for sh3. - tst r7,r0 + tst r7,r0 You have to be careful with the whitespace. > 2) Infinity in divsf3.S was not set (case of 1.0/0.0). > * config/sh/IEEE-754/m3/divsf3.S: Intialize xff00 label. > This was supposed to be: LOCAL(m1): .word -1 .balign 4 LOCAL(xff00): #ifdef __LITTLE_ENDIAN__ .word 0 LOCAL(xff00): .word 0xff00 #else LOCAL(xff00): .word 0xff00 .word 0 #endif saving four bytes over using unshared constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-02-01 04:23 --- (In reply to comment #5) > I'll take a look. Any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug c/30661] New: mayalias-2.c, mayalias-3.c fail at -O3 -g with --enable-checking=yes
With an --enable-checking=yes build of the tree at at svn 121332, the following testsuite errors appear: Executing on host: /home/brooks/gcc-callexpr/build2/gcc/xgcc -B/home/brooks/gcc-callexpr/build2/gcc/ /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c -w -O3 -g -fno-show-column -lm -o /home/brooks/gcc-callexpr/build2/gcc/testsuite/gcc/mayalias-2.x4(timeout = 300) /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal compiler error) [...] Executing on host: /home/brooks/gcc-callexpr/build2/gcc/xgcc -B/home/brooks/gcc-callexpr/build2/gcc/ /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c -w -O3 -g -fno-show-column -lm -o /home/brooks/gcc-callexpr/build2/gcc/testsuite/gcc/mayalias-3.x4(timeout = 300) /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /home/brooks/gcc-callexpr/svn-source/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compiler error) [...] -- Summary: mayalias-2.c, mayalias-3.c fail at -O3 -g with --enable- checking=yes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30661
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2007-02-01 06:13 --- Subject: Re: "make check" fails to compile library testcases >> I'll take a look. > > Any ideas? Sure, I'm just a little busy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug fortran/24978] ICE in gfc_assign_data_value_range
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/25057] default initialization and DATA statement conflict
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25057
[Bug libfortran/30162] I/O with named pipes does not work
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug bootstrap/30662] New: bootstrap fails on x86-64
../gcc/configure --prefix=/pkg/gcc-4.3-$(date +%y%m%d) --enable-languages=c,c++ --disable-checking --disable-i18n As of mainline with last ChangeLog 2007-02-01 Ralf Wildenhues <[EMAIL PROTECTED]> * doc/c-tree.texi (Expression trees): Improve markup. * doc/tm.texi (Register Classes, Addressing Modes) (Floating Point): Fix spacing after abbreviations. Fix some typos. With make bootstrap I get an ICE during building of libgcc2: /home/andi/gcc/head/obj/./gcc/xgcc -B/home/andi/gcc/head/obj/./gcc/ -B/pkg/gcc-4.3-070201/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.3-070201/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.3-070201/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.3-070201/x86_64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -I../../../gcc/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function __multi3: ../../../gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error: Segmentation fault Program received signal SIGSEGV, Segmentation fault. 0x005d0259 in emit_move_insn (x=0x2ba5d9c3b580, y=0x0) at ../../gcc/gcc/expr.c:3310 3310 gcc_assert (mode != BLKmode (gdb) bt #0 0x005d0259 in emit_move_insn (x=0x2ba5d9c3b580, y=0x0) at ../../gcc/gcc/expr.c:3310 #1 0x00c84c32 in resolve_simple_move (set=0x2ba5d9c37720, insn=0x2ba5d9c21af0) at ../../gcc/gcc/lower-subreg.c:746 #2 0x00c8550c in decompose_multiword_subregs (update_life=0 '\0') at ../../gcc/gcc/lower-subreg.c:1003 #3 0x00c85b52 in rest_of_handle_lower_subreg () at ../../gcc/gcc/lower-subreg.c:1083 #4 0x0073cadd in execute_one_pass (pass=0x11210c0) at ../../gcc/gcc/passes.c:1020 #5 0x0073cc22 in execute_pass_list (pass=0x11210c0) at ../../gcc/gcc/passes.c:1071 #6 0x0073cc40 in execute_pass_list (pass=0x111cb00) at ../../gcc/gcc/passes.c:1072 #7 0x00869f02 in tree_rest_of_compilation (fndecl=0x2ba5d9c01460) at ../../gcc/gcc/tree-optimize.c:475 #8 0x0042afca in c_expand_body (fndecl=0x2ba5d9c01460) at ../../gcc/gcc/c-decl.c:6851 #9 0x00a512a5 in cgraph_expand_function (node=0x2ba5d9c14ee0) at ../../gcc/gcc/cgraphunit.c:988 #10 0x00a51455 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1051 #11 0x00a51a4f in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1254 #12 0x0042e342 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7965 #13 0x007fce27 in compile_file () at ../../gcc/gcc/toplev.c:1039 #14 0x007fe993 in do_compile () at ../../gcc/gcc/toplev.c:2091 #15 0x007fe9f7 in toplev_main (argc=27, argv=0x7fffd1c036d8) at ../../gcc/gcc/toplev.c:2123 #16 0x004d3d0b in main (argc=27, argv=0x7fffd1c036d8) at ../../gcc/gcc/main.c:35 (gdb) p y $2 = (rtx) 0x0 (gdb) pr x (reg:DI 92 [ u+8 ]) -- Summary: bootstrap fails on x86-64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ak at muc dot de GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30662
"internal compiler error": is this a known problem?
I have used http://www.kegel.com/crosstool/crosstool-0.42.tar.gz to (attempt to) build GCC 4.1.0 as a cross compiler (x86 => arm) and I get the following message during the build process: ../sysdeps/generic/s_fmax.c: In function `__fmax': ../sysdeps/generic/s_fmax.c:28: internal compiler error: in elim_reg_cond, at flow.c:3328 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I want to ask: does this look like a known problem? Forgive me, but turning this into a fully reproducible bug report is going to be a *lot* of work, particularly as the problem appears to occur deep in the building of glibc ... I'm reluctant to start working on this unless there's a real interest in a detailed report on this problem. For what it's worth (yes, yes, this isn't a proper bug report) I used the following commands in crosstool-0.42 to do the build: set -aex export TARBALLS_DIR=/some/convenient/dir export RESULT_TOP=/another/convenient/dir export GCC_LANGUAGES="c,c++" . arm.dat . gcc-4.1.0-glibc-2.3.6.dat TARGET=arm-linux sh -ex ./all.sh --notest A little environment information: `uname -msro` => Linux 2.6.9-34.ELsmp i686 GNU/Linux and it's a Red Hat Enterprise box of some sort.
[Bug bootstrap/30662] bootstrap fails on x86-64
--- Comment #1 from grigory_zagorodnev at linux dot intel dot com 2007-02-01 07:54 --- This is due to http://gcc.gnu.org/ml/gcc-patches/2007-02/msg2.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30662
