[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-07 08:50 --- (In reply to comment #2) This looks related to 31218, so I'm adding a dependency even though I'm not certain it's the same. Also confirming, because it's definitely a bug even if it's a duplicate one. It might be - the problem is specifically due to achar not producing a character length. If you separate the expression for the first argument of the outer transfer into a character*(1) :: tmp(20), the code works because the character size of tmp is used. Hanging a diagnostic just before the gcc_assert, confirms that this expression does not have a ts.cl. Strangely, there is no gfc_resolve_achar function to do this. I can feel a fix coming on...:) 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 Last reconfirmed|2007-04-06 23:12:54 |2007-04-07 08:50:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug fortran/31404] ICE len_trim(array) in initialization
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-07 08:54 --- This is fixed by the patch that I submitted for PR29507. 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 Last reconfirmed|2007-03-31 22:56:47 |2007-04-07 08:54:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31404
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #8 from paolo at gcc dot gnu dot org 2007-04-07 09:38 --- Subject: Bug 31481 Author: paolo Date: Sat Apr 7 09:38:39 2007 New Revision: 123637 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123637 Log: 2007-04-07 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31481 * include/ext/type_traits.h (__numeric_traits): Move... * include/ext/numeric_traits.h: ... here; fix type of __max_digits10. * include/Makefile.am: Add. * include/ext/pb_ds/detail/type_utils.hpp: Include ext/numeric_traits.h too. * include/tr1/random: Likewise. * testsuite/ext/type_traits/numeric_traits.cc: Move... * testsuite/ext/numeric_traits/numeric_traits.cc: ... here. * include/Makefile.in: Regenerate. * testsuite/ext/type_traits/remove_unsigned_integer_neg.cc: Adjust dg-error line number. * testsuite/ext/type_traits/add_unsigned_floating_neg.cc: Likewise. * testsuite/ext/type_traits/remove_unsigned_floating_neg.cc: Likewise. * testsuite/ext/type_traits/add_unsigned_integer_neg.cc: Likewise. Added: branches/gcc-4_2-branch/libstdc++-v3/include/ext/numeric_traits.h branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/numeric_traits/ branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/numeric_traits/numeric_traits.cc Removed: branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/type_traits/numeric_traits.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.in branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/type_utils.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/type_traits.h branches/gcc-4_2-branch/libstdc++-v3/include/tr1/random branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_integer_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #9 from pcarlini at suse dot de 2007-04-07 09:39 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug c++/31502] New: gcc/g++ randomly seg faults, sometimes freezes the entire machine
Machine info: CPU: AMD 4200+ (64 bit) RAM: 3G DDR OS info: Type: Linux Distro: Ubuntu Edgy 6.10 Kernel: 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linu Bit: 32 bit OS Overview of the problem: gcc and g++ would frequently and randomly seg faults, and this would sometimes freeze the machine and force the reset button to be pressed. Code on which these errors have occurred: mplayer 1.0pre8, Blender. Example of compilation command that produces the error: gcc -c -O3 -g -Wdeclaration-after-statement -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -I/home/jingy/install/blender/cvs_new/blender/extern/ffmpeg/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -DMOZ_NOT_NET snow.c -o /home/jingy/install/blender/cvs_new/blender/obj/linux-glibc2.4-i386/extern/ffmpeg/libavcodec/snow.o Output of the compiler: --- snow.c: In function pred_mv: snow.c:1961: warning: suggest parentheses around + or - inside shift snow.c:1962: warning: suggest parentheses around + or - inside shift snow.c:1963: warning: suggest parentheses around + or - inside shift snow.c:1964: warning: suggest parentheses around + or - inside shift snow.c:1965: warning: suggest parentheses around + or - inside shift snow.c:1966: warning: suggest parentheses around + or - inside shift snow.c: In function encode_q_branch: snow.c:1994: warning: initialization discards qualifiers from pointer target type snow.c:1995: warning: initialization discards qualifiers from pointer target type snow.c:1996: warning: initialization discards qualifiers from pointer target type snow.c:1997: warning: initialization discards qualifiers from pointer target type snow.c: In function encode_q_branch2: snow.c:2221: warning: initialization discards qualifiers from pointer target type snow.c:: warning: initialization discards qualifiers from pointer target type snow.c: In function decode_q_branch: snow.c:2274: warning: initialization discards qualifiers from pointer target type snow.c:2275: warning: initialization discards qualifiers from pointer target type snow.c: In function pred_block: snow.c:2497: warning: suggest parentheses around within || snow.c: In function ff_snow_inner_add_yblock: snow.c:2538: warning: left shift count is negative snow.c: In function add_yblock_buffered: snow.c:2567: warning: unused variable y snow.c:2567: warning: unused variable x snow.c:2555: warning: unused variable dst snow.c: In function add_yblock: snow.c:2809: warning: initialization discards qualifiers from pointer target type snow.c:2821: warning: left shift count is negative snow.c: In function predict_slice_buffered: snow.c:2896: warning: passing argument 5 of add_yblock_buffered discards qualifiers from pointer target type snow.c: In function get_block_bits: snow.c:3028: warning: initialization discards qualifiers from pointer target type snow.c:3029: warning: initialization discards qualifiers from pointer target type snow.c: In function get_block_rd: snow.c:3065: warning: unused variable obmc snow.c: In function get_4block_rd: snow.c:3182: warning: passing argument 2 of add_yblock discards qualifiers from pointer target type snow.c:3168: warning: unused variable b_height snow.c: In function common_init: snow.c:3872: warning: assignment from incompatible pointer type snow.c:3872: warning: assignment from incompatible pointer type snow.c:3873: warning: assignment from incompatible pointer type snow.c:3873: warning: assignment from incompatible pointer type snow.c:3874: warning: assignment from incompatible pointer type snow.c:3874: warning: assignment from incompatible pointer type snow.c:3875: warning: assignment from incompatible pointer type snow.c:3875: warning: assignment from incompatible pointer type snow.c: At top level: snow.c:1327: warning: spatial_compose53i defined but not used snow.c:1494: warning: spatial_compose97i defined but not used snow.c: In function get_dc: snow.c:3021: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. The bug is not reproducible, so it is likely a hardware or OS problem. make[3]: *** [/home/jingy/install/blender/cvs_new/blender/obj/linux-glibc2.4-i386/extern/ffmpeg/libavcodec/snow.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 --- The output of the preprocessor (snow.i) can be downloaded from: http://www.csse.unimelb.edu.au/~jingy/download/snow.i Sometimes these errors would be immediately followed by a kernel warning stating some memory protection has failed. Sometimes these errors would be so severe that no other processes can be run. Please feel free to contact me for further information. Thanks a lot. Patrick -- Summary: gcc/g++
[Bug preprocessor/14331] please add option to suppress warning message no newline at end of file
--- Comment #13 from dave dot korn at artimi dot com 2007-04-07 14:07 --- Manu: I was not criticizing your patch. [ ... ] So sorry, I didn't mean you to think I was offended! I took your comment completely at face value. [ ... ] I hope this helps. It most certainly does! I am testing a revised and updated patch. cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug fortran/31399] Wrong code for do loop with large interation count
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-07 14:15 --- Created an attachment (id=13337) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13337action=view) Patch -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31399
[Bug c++/31503] New: gcc exhausts memory when compiling pixie with optimizations
Steps to reproduce: 1. Download Pixie 2.1.1 from https://sourceforge.net/project/showfiles.php?group_id=59462 2. untar and configure 3. Try to compile with make, specifically Pixie/src/ri/execute.cpp Memory usage blows up and g++ gets killed. Compiling with make CXXFLAGS=-g works. -- Summary: gcc exhausts memory when compiling pixie with optimizations Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gonsolo 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=31503
[Bug c++/31502] gcc/g++ randomly seg faults, sometimes freezes the entire machine
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-07 15:30 --- If GCC is causing your machine to freeze, there is only one possibility, your machine is over heating and this is not a GCC bug. I think you need to check your hardware. Also if you are getting messages from the kernel, it shoulds like you really need to check your hardware. -- 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=31502
[Bug c++/31502] gcc/g++ randomly seg faults, sometimes freezes the entire machine
--- Comment #2 from ye dot patrick at gmail dot com 2007-04-07 15:43 --- I did think overheating was an issue, but then I turned off the computer for half an hour then turned it back on to compile the same code and the same error occurred. The temperature of my room at the time was below 20 degrees, so I'm not totally convinced that this is an overheating issue. I'm willing to accept this as an hardware/OS issue, but then am I really that unlikely to be the only person having this kind of problem? In other words, has this type of problems been seen before and if so, how were they resolved? Any help would be greatly appreciated. Thanks a lot. Patrick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31502
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #4 from patchapp at dberlin dot org 2007-04-07 15:45 --- Subject: Bug number PR31257 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-04/msg00321.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug preprocessor/14331] please add option to suppress warning message no newline at end of file
-- pbrook at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dave dot korn at artimi dot |dot org |com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug testsuite/31369] 100's of new libgomp fails
--- Comment #6 from danglin at gcc dot gnu dot org 2007-04-07 16:10 --- Subject: Bug 31369 Author: danglin Date: Sat Apr 7 16:10:06 2007 New Revision: 123638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123638 Log: PR testsuite/31369 * testsuite/libgomp.c++/c++.exp: Don't use concat when setting ld_library_path. * testsuite/libgomp.fortran/fortran.exp: Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c++/c++.exp trunk/libgomp/testsuite/libgomp.fortran/fortran.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31369
[Bug testsuite/31369] 100's of new libgomp fails
--- Comment #7 from danglin at gcc dot gnu dot org 2007-04-07 16:13 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31369
[Bug c++/31489] error says struct when it should say class
--- Comment #2 from bangerth at dealii dot org 2007-04-07 16:23 --- Confirmed. I think a patch would be of interest. Maybe one could just tweak the error to read x.cc:5: error: invalid use of undefined type 'foobar' x.cc:1: error: forward declaration of struct or class 'foobar' -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-07 16:23:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489
[Bug c++/31502] gcc/g++ randomly seg faults, sometimes freezes the entire machine
--- Comment #3 from bangerth at dealii dot org 2007-04-07 16:29 --- (In reply to comment #2) I'm willing to accept this as an hardware/OS issue, but then am I really that unlikely to be the only person having this kind of problem? In other words, has this type of problems been seen before and if so, how were they resolved? There's an easy way to figure out whether it's the compiler's fault or that of your machine: does the error always happen on the same file, with the exact same error message? Since gcc is a deterministic program, it would have to cause the same problem every time you compile the same file. On the other hand, if the error appears randomly even though you compile the same set of files, then this clearly can't be gcc's fault. It certainly sounds like a hardware problem (memory, overheating, disk, ...) W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31502
[Bug ada/31504] New: GCC error: in staticp, at tree.c:2017
/home/dave/gnu/gcc-4.3/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -gna tpg -gnata -g -O1 -fno-inline \ -I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/a-except.adb -o ada /a-except.o +===GNAT BUG DETECTED==+ | 4.3.0 20070407 (experimental) (hppa-unknown-linux-gnu) GCC error:| | in staticp, at tree.c:2017 | | Error detected at a-exexda.adb:239:40| | 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. -- Summary: GCC error: in staticp, at tree.c:2017 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31504
[Bug fortran/31471] gfortran does not detect a labeled FORALL with an unlabeled END FORALL
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-07 16:49 --- I'll look into this during the next week. The same bug seems to be present with WHERE. Fix should be trivial. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-04 17:39:07 |2007-04-07 16:49:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31471
[Bug c++/31505] New: Canonical types failures
For the attached (unfortunately rather lengthy) file I finally managed to get a reproducible testcase that spews out several pages of canonical types warning messages when compiled with -O2 (but not with -O0): examples/step-27 /tmp/bangerth/bin/gcc-mainline/bin/g++ -c step-27.ii -O2 step-27.cc: In member function 'void LaplaceProblemdim::create_coarse_grid() [with int dim = 2]': step-27.cc:742: warning: same canonical type node for different types dealii::Point2 [24] and const dealii::Point2 [24] array_type 0xb4cef8dc type record_type 0xb7459bd0 Point sizes-gimplified addressable needs-constructing type_1 type_5 type_6 BLK size integer_cst 0xb7d5e834 constant invariant 128 unit size integer_cst 0xb7d5e850 constant invariant 16 align 32 symtab 0 alias set 147 canonical type 0xb7459bd0 fields field_decl 0xb5f54a20 D.74077 type record_type 0xb745472c Tensor ignored decl_6 BLK file /tmp/bangerth/x/deal.II/base/include/base/tensor_base.h line 39 size integer_cst 0xb7d5e834 128 unit size integer_cst 0xb7d5e850 16 align 32 offset_align 128 offset integer_cst 0xb7d5e444 constant invariant 0 bit offset integer_cst 0xb7d5eb28 constant invariant 0 context record_type 0xb7459bd0 Point chain type_decl 0xb5f8a438 Point context namespace_decl 0xb7e25870 dealii needs-constructor X() X(constX) this=(X) n_parents=1 use_template=1 interface-unknown pointer_to_this pointer_type 0xb5f8a510 reference_to_this reference_type 0xb5f8e0d8 chain type_decl 0xb7459c3c Point sizes-gimplified needs-constructing BLK ... I hope this helps to track a few things down. I have a couple of other files that show canonical types fail as well, but there the bug goes away once one uses -save-temps :-( Best Wolfgang -- Summary: Canonical types failures Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug fortran/31466] spurious error message when inner parentheses of a FORMAT statement are empty
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-07 16:54 --- I verified Tobias' reading of the standard. Closing as invalid. Perhaps the error message could be more helpful. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31466
[Bug c++/31506] New: Canonical types failures
For the attached (unfortunately rather lengthy) file I finally managed to get a reproducible testcase that spews out several pages of canonical types warning messages when compiled with -O2 (but not with -O0): examples/step-27 /tmp/bangerth/bin/gcc-mainline/bin/g++ -c step-27.ii -O2 step-27.cc: In member function 'void LaplaceProblemdim::create_coarse_grid() [with int dim = 2]': step-27.cc:742: warning: same canonical type node for different types dealii::Point2 [24] and const dealii::Point2 [24] array_type 0xb4cef8dc type record_type 0xb7459bd0 Point sizes-gimplified addressable needs-constructing type_1 type_5 type_6 BLK size integer_cst 0xb7d5e834 constant invariant 128 unit size integer_cst 0xb7d5e850 constant invariant 16 align 32 symtab 0 alias set 147 canonical type 0xb7459bd0 fields field_decl 0xb5f54a20 D.74077 type record_type 0xb745472c Tensor ignored decl_6 BLK file /tmp/bangerth/x/deal.II/base/include/base/tensor_base.h line 39 size integer_cst 0xb7d5e834 128 unit size integer_cst 0xb7d5e850 16 align 32 offset_align 128 offset integer_cst 0xb7d5e444 constant invariant 0 bit offset integer_cst 0xb7d5eb28 constant invariant 0 context record_type 0xb7459bd0 Point chain type_decl 0xb5f8a438 Point context namespace_decl 0xb7e25870 dealii needs-constructor X() X(constX) this=(X) n_parents=1 use_template=1 interface-unknown pointer_to_this pointer_type 0xb5f8a510 reference_to_this reference_type 0xb5f8e0d8 chain type_decl 0xb7459c3c Point sizes-gimplified needs-constructing BLK ... I hope this helps to track a few things down. I have a couple of other files that show canonical types fail as well, but there the bug goes away once one uses -save-temps :-( Best Wolfgang -- Summary: Canonical types failures Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31506
[Bug c++/31506] Canonical types failures
--- Comment #1 from bangerth at dealii dot org 2007-04-07 16:55 --- Ack, using the back button over PR submissions is no good... *** This bug has been marked as a duplicate of 31505 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31506
[Bug c++/31505] Canonical types failures
--- Comment #1 from bangerth at dealii dot org 2007-04-07 16:55 --- *** Bug 31506 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug c++/31505] Canonical types failures
--- Comment #2 from bangerth at dealii dot org 2007-04-07 16:59 --- For some reason, bugzilla gives me an internal error when I try to attach the file. In any case, it is here: http://www.math.tamu.edu/~bangerth/step-27.ii.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-07 17:04 --- (In reply to comment #4) (In reply to comment #3) But even if it is the case, the compiler should report an error. This is not a requirement of the standard but is a long standing regression, relative to g77. Really? From how I read the standard (F2K draft), UBOUND(ARRAY, DIM) has (in this case) a value equal to the upper bound for subscript DIM of ARRAY. I can't see it allowing returning random values such as 2193121. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-07 17:05 --- *** Bug 31414 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31414] Non-integer expression as character length
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-07 17:05 --- Trying to break PaulT's heart by artificially increasing our bug count, FX? :-) *** This bug has been marked as a duplicate of 31251 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31414
[Bug fortran/30998] Big code with assigned goto's loops with optimization
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-07 17:09 --- Waiting for more than 5 weeks should be enough. Please reopen if you come forth with a testcase. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30998
[Bug c++/31506] Canonical types failures
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-07 17:28 --- Ack, using the back button over PR submissions is no good... Which has been fixed in bugzilla 3.0 so when we upgrade, that problem will be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31506
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #5 from danglin at gcc dot gnu dot org 2007-04-07 17:29 --- Richard, Since you added these tests, do you have any thoughts as to what should be done regarding these fails. Clearly, these tests invoke undefined behavior, so the compiler can ICE. On the otherhand, the compiler shouldn't ICE. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-07 17:35 --- This is just like PR 12535 where DSE is trying to remove part of the prologue/epilogue also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug rtl-optimization/12535] Attempt to delete prologue/epilogue insn
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-07 17:36 --- Simplified testcase. This bug is probably a WONTFIX. No, it should not be a WONTFIX. The DSE implementation should try not to delete part of prologue/epilogue . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12535
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-07 17:38 --- Basically flow (or really the DSE part of flow) should be taught that the prologue/epilogue is special and should not be deleted. Maybe a good idea is to see if the dataflow branch with its new DSE gets this ICE also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-07 18:01 --- Subject: Re: FAIL: gcc.dg/Warray-bounds.c (internal compiler error) This is just like PR 12535 where DSE is trying to remove part of the prologue/epilogue also. Looks similar. Particularly, the compiler shouldn't ICE when a memory write in user code stomps on memory used by prologue/epilogue insns as this is likely to be fairly common. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug libfortran/31501] libgfortran I/O performance issues
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-07 18:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31501
[Bug c++/31505] Canonical types failures
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-07 20:25 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-07 21:14 --- Subject: Bug 31293 Author: pault Date: Sat Apr 7 21:13:52 2007 New Revision: 123641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123641 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31293 * symbol.c (gfc_check_function_type): New function. * gfortran.h : Add prototype for previous. * parse.c (parse_progunit): Call it after parsing specification statements. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31293 * gfortran.dg/interface_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-07 21:18 --- Subject: Bug 31424 Author: pault Date: Sat Apr 7 21:18:17 2007 New Revision: 123642 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123642 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31214 * trans-decl.c (gfc_get_symbol_decl): Allow unreferenced use associated symbols. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31424 * gfortran.dg/unreferenced_use_assoc_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unreferenced_use_assoc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
[Bug fortran/31214] User-defined operator using entry leads to ICE
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-07 21:18 --- Subject: Bug 31214 Author: pault Date: Sat Apr 7 21:18:17 2007 New Revision: 123642 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123642 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31214 * trans-decl.c (gfc_get_symbol_decl): Allow unreferenced use associated symbols. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31424 * gfortran.dg/unreferenced_use_assoc_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unreferenced_use_assoc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-07 21:21 --- Subject: Bug 31222 Author: pault Date: Sat Apr 7 21:20:49 2007 New Revision: 123643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123643 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31222 * check.c (numeric_check): If an expresson has not got a type, see if it is a symbol for which a default type applies. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31222 * gfortran.dg/default_numeric_type_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/default_numeric_type_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug libffi/31507] New: libffi regression, many.c, closure_fn2/fn3.c with -Os
The mentioned test cases produce an ICE in reload.c:3737 Attached. Also the preprocessed source for closure_fn3.c I can not cp with firefox atm. -- Summary: libffi regression, many.c, closure_fn2/fn3.c with -Os Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org GCC build triplet: x86_64-apple-darwin8 GCC host triplet: x86_64-apple-darwin8 GCC target triplet: x86_64-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
[Bug libffi/31507] libffi regression, many.c, closure_fn2/fn3.c with -Os
--- Comment #1 from andreast at gcc dot gnu dot org 2007-04-07 21:23 --- Created an attachment (id=13338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13338action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
[Bug fortran/30872] Bogus size of variable is too large
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-07 21:23 --- Subject: Bug 30872 Author: pault Date: Sat Apr 7 21:23:40 2007 New Revision: 123644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123644 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/30872 * expr.c (find_array_element): Correct arithmetic for rank 1. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/30872 * gfortran.dg/parameter_array_element_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_element_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30872
[Bug libffi/31507] libffi regression, many.c, closure_fn2/fn3.c with -Os
--- Comment #2 from andreast at gcc dot gnu dot org 2007-04-07 21:24 --- Created an attachment (id=13339) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13339action=view) error text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
[Bug fortran/30880] Derived types with default value -- function with ENTRY: rejected at compile time
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-07 21:25 --- Subject: Bug 30880 Author: pault Date: Sat Apr 7 21:25:43 2007 New Revision: 123645 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123645 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/30880 * resolve.c (resolve_fl_variable): Set flag to 2 for automatic arrays. Make condition for automatic array error explicit. If a dummy, no error on an INTENT(OUT) derived type. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/30880 * gfortran.dg/used_dummy_types_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_dummy_types_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30880
[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|libffi |target Summary|libffi regression, many.c, |[4.3 Regression] libffi |closure_fn2/fn3.c with -Os |regression, many.c, ||closure_fn2/fn3.c with -Os Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-07 21:29 --- Subject: Bug 31257 Author: pault Date: Sat Apr 7 21:29:13 2007 New Revision: 123646 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123646 Log: 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31257 * intrinsic.c (add_functions): Add ref. to gfc_resolve_achar. * intrinsic.h : Add prototype for gfc_resolve_achar. * iresolve.c (gfc_resolve_achar): New function. 2007-04-07 Paul Thomas [EMAIL PROTECTED] PR fortran/31257 * gfortran.dg/achar_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/achar_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug fortran/31214] User-defined operator using entry leads to ICE
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-07 21:31 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-07 21:32 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- Comment #6 from pault at gcc dot gnu dot org 2007-04-07 21:32 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug fortran/30872] Bogus size of variable is too large
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-07 21:33 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30872
[Bug fortran/30880] Derived types with default value -- function with ENTRY: rejected at compile time
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-07 21:33 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30880
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #6 from pault at gcc dot gnu dot org 2007-04-07 21:34 --- Fixed on trumk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug target/30289] avr-gcc: builtin memset(): wrong code
--- Comment #2 from aesok at gcc dot gnu dot org 2007-04-07 23:00 --- Subject: Bug 30289 Author: aesok Date: Sat Apr 7 23:00:33 2007 New Revision: 123647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123647 Log: PR target/30289 * config/avr/avr.md (*clrmemqi, *clrmemhi): Mark operand 4 as earlyclobber. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289
[Bug target/30289] avr-gcc: builtin memset(): wrong code
--- Comment #3 from aesok at gcc dot gnu dot org 2007-04-07 23:15 --- Subject: Bug 30289 Author: aesok Date: Sat Apr 7 23:14:51 2007 New Revision: 123648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123648 Log: PR target/30289 * config/avr/avr.md (*clrmemqi, *clrmemhi): Mark operand 4 as earlyclobber. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289
[Bug target/30289] avr-gcc: builtin memset(): wrong code
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-07 23:21 --- Subject: Bug 30289 Author: aesok Date: Sat Apr 7 23:21:01 2007 New Revision: 123649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123649 Log: PR target/30289 * config/avr/avr.md (*clrmemqi, *clrmemhi): Mark operand 4 as earlyclobber. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289
[Bug target/30289] avr-gcc: builtin memset(): wrong code
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-07 23:23 --- Fixed in 4.1, 4.2 branch, and HEAD. -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289
[Bug ada/31504] GCC error: in staticp, at tree.c:2017
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-04-07 23:40 --- See on-list discussion, but basically, it should suffice to simply remove the assert, which will give the Ada frontend the same behavior it used to get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31504
[Bug c++/31505] Canonical types failures
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-08 00:05 ---
I bet a beer that this is related to code like:
int a[] = {1,2};
The only reason I am saying that is because the last time I looked into a
failure of giving the same aliasing set to int[] = {1,2} as int[2] was the same
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug ada/31504] GCC error: in staticp, at tree.c:2017
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-04-08 00:50 --- Patch was reverted -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31504
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #5 from bangerth at dealii dot org 2007-04-08 00:54 --- (In reply to comment #4) ive no idea which part of the standard should imply/allow this. if one replaces typename T::privIC * priv with T * priv, its valid and it compiles. I thought T::privC is equally accessible 'incomplete' as T itself when instantiating the template. Yes, but the difference is that we know what T is (and that it exists) because it was given as a template argument. We don't know this about T::privIC -- it may not exist for certain types given as T, but we can't know without looking into T, which we can't because T isn't complete. I am confident that the code isn't valid because at the point of use T::privIC hasn't been declared yet. Since in addition none of the other compilers you cite support this idiom, I'll close this PR. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31382] Internal compiler Error (Is this a bug?)
--- Comment #1 from bangerth at dealii dot org 2007-04-08 00:56 --- An internal compiler error is always a bug on our side. Please follow the guidelines at http://gcc.gnu.org/bugs.html and supply us with the information listed there. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31382
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #2 from bangerth at dealii dot org 2007-04-08 00:58 --- (In reply to comment #1) Do you mean -Woverloaded-virtual? (see man page) The diagostic reports when a derived class's method 'hides' the base class's. No, he simply wants to know that it doesn't matter from a semantic point, but just to make the declaration clearer, why don't you add a 'virtual' to your destructor and int f(int) functions, because they are implicitly virtual anyway'. Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-04-08 00:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31445] [4.3 regression] type_argument_pack not supported by dump_type
--- Comment #1 from bangerth at dealii dot org 2007-04-08 01:01 --- I also find this a bit weird: bug.cc:4: error: parameter packs not expanded with `...': bug.cc:4: note: 't' If the error ends with a colon, then the variable name should also be listed as part of the error message, not as a separate note. Also, the typical wording would be: error: parameter pack 't' not expended with `...' in keeping with other messages. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31445
[Bug c++/31503] gcc exhausts memory when compiling pixie with optimizations
--- Comment #1 from bangerth at dealii dot org 2007-04-08 01:03 --- Please follow the steps outlined at http://gcc.gnu.org/bugs.html . In particular, we'll need a preprocessed source file. It would also be of interest how much memory you see that this testcase actually consumes before it gets killed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31503
[Bug c++/31502] gcc/g++ randomly seg faults, sometimes freezes the entire machine
--- Comment #4 from ye dot patrick at gmail dot com 2007-04-08 04:39 --- The error occurs extremely often on the same files, but not all the time. For example, if I was to compile snow.c (the file that generated the error in my initial report) 10 times, it would have the same error 6-8 times. Furthermore, if you read the bottom of the error message, it says: The bug is not reproducible, so it is likely a hardware or OS problem. I'm willing to accept this as an OS problem, and I'm just wondering if anyone else has reported the same problem and if so, what the solution was. Thanks a lot. Patrick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31502
[Bug c++/31505] [4.3 Regression] Canonical types failures
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-08 05:55 ---
Reduced testcase (which makes I am correct):
template int dim struct Point
{
Point (const double x, const double y);
};
Point2 f(void) {}
void create_coarse_grid () {
static const Point2 vertices_1[]
= {
Point2 (-1., -1.),
Point2 (-1./2, -1.),
Point2 (0., -1.),
Point2 (+1./2, -1.)
};
}
=
If I change [] to [4] then it works.
--
pinskia 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-04-08 05:55:43
date||
Summary|Canonical types failures|[4.3 Regression] Canonical
||types failures
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
