[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms
--- Comment #12 from patchapp at dberlin dot org 2006-10-18 07:01 --- Subject: Bug number PR29277 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/2006-10/msg00887.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug target/29338] [4.1 regression] ICE on valid C++ code
--- Comment #5 from debian-gcc at lists dot debian dot org 2006-10-18 07:35 --- works with 4.1 4.1.2 20061015, closing. Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29338
[Bug java/29495] New: [ecj] some field & method flags not passed through
Currently the modifier flags synthetic and enum for fields; and synthetic, bridge, and varargs for methods; are not passed through gcj and put into the resulting structures in the object code. -- Summary: [ecj] some field & method flags not passed through Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29495
[Bug c++/29496] New: _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
_M_invalidate function in safe_iterator.tcc is not thread safe against
_M_detach()/_M_attach() functions from _Safe_iterator_base.
Here is the example of erronous scenario:
Thread1()
{
list::iterator iter;
lock(mutex);
iter = myList.begin();
// do something with iter
unlock();
}
Thread2()
{
lock(mutex);
myList.erase(myList.begin());
unlock();
}
The problem in this scenario is that while calling erase(), _M_invalidate()
function is called which goes through the list of all iterators without taking
a lock on __gnu_internal::iterator_base_mutex. At the same time another thread
can be deallocating lists iterator - thus calling _M_detach() function.
This leads to a SIGSEGV in _M_invalidate() function.
You should either remove concurrency support from GLIBCXX_DEBUG mode or provide
full support.
--
Summary: _M_invalidate function is not thread-safe in
GLIBCXX_DEBUG mode
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l_heldt at poczta dot onet dot pl
GCC host triplet: Linux 2.6.9-42.ELsmp #1 SMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug fortran/29497] New: Problem with preprocessor directive -x f95-cpp-input
On Mac OS X PowerPC G4, I type: gfortran -x f95-cpp-input -DNDIM=3 toto.f90 -o toto and the compilation of the source was OK, but at link time, I got In file toto.o:1 \xFE\xED\xFA\xCE\x12\x01\x03\x01( \x01\xC0\x9D\xA0\x01D\x9D\xA0\x07\x07\x02__text__TEXT\x01D\x80__data__DATA\x9D\xA0\x01D\x03\x02\x18\x9E\xE4^\xA3L 1 Error: Unclassifiable statement at (1) So I tried to remove the preprocessor directive gfortran toto.o -o toto and everything went fine ! It is a minor problem, but, if cured, it will make compilation and link working at the same time, a more comfortable situation. Cheers; Romain -- Summary: Problem with preprocessor directive -x f95-cpp-input Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: romain dot teyssier at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29497
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #1 from pcarlini at suse dot de 2006-10-18 09:00 --- Benjamin and Doug, can you have a look to this issue? Thanks. -- pcarlini at suse dot de changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com, bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Comment #3 from patchapp at dberlin dot org 2006-10-18 09:10 --- Subject: Bug number PR22372 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/2006-10/msg00892.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug target/29498] New: FTZ/DAZ for SSE should be ported to mingw32
See http://gcc.gnu.org/ml/gcc/2005-08/msg00284.html. IMHO it's currently only working for Linux. Given the author has claimed a big performance boost with this patch, I guess it should be ported mingw32 since it's also an i386 host. -- Summary: FTZ/DAZ for SSE should be ported to mingw32 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuxy dot meng at gmail dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
[Bug c++/27787] Qualified lookup fails to find inherited class template
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-18 09:18 --- Subject: Bug 27787 Author: rguenth Date: Wed Oct 18 09:18:07 2006 New Revision: 117852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117852 Log: 2006-10-18 Richard Guenther <[EMAIL PROTECTED]> PR C++/25878 Backport from mainline: 2006-08-25 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/27787 * decl.c (make_typename_type): Only try and resolve it when context is not dependent. Refactor. * decl2.c (check_classfn): Push to class scope before looking * for the function. * g++.dg/template/typename10.C: New. * g++.dg/template/lookup4.C: Remove bogus error marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/typename10.C - copied unchanged from r116409, trunk/gcc/testsuite/g++.dg/template/typename10.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/lookup4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-18 09:18 --- Subject: Bug 25878 Author: rguenth Date: Wed Oct 18 09:18:07 2006 New Revision: 117852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117852 Log: 2006-10-18 Richard Guenther <[EMAIL PROTECTED]> PR C++/25878 Backport from mainline: 2006-08-25 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/27787 * decl.c (make_typename_type): Only try and resolve it when context is not dependent. Refactor. * decl2.c (check_classfn): Push to class scope before looking * for the function. * g++.dg/template/typename10.C: New. * g++.dg/template/lookup4.C: Remove bogus error marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/typename10.C - copied unchanged from r116409, trunk/gcc/testsuite/g++.dg/template/typename10.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/lookup4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c++/25868] [4.0 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-18 09:18 --- Fixed on the 4.1 branch by backporting the fix for PR27787. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27787 Summary|[4.0/4.1 Regression]|[4.0 Regression] Multiple |Multiple templates and |templates and typedefs cause |typedefs cause function |function prototype not to |prototype not to match |match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug gcov-profile/26570] [4.1 Regression] -fprofile-generate -fprofile-use cause memory corruption immediately
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-18 09:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26570
[Bug tree-optimization/16876] [4.0/4.1 Regression] ICE on testcase with -O3 in fold-const
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-10-18 09:26 --- A backport of the patch bootstraps & regtests ok on the 4.1 branch, but I'm unsure we want the side-effects of the rejects-valid, because this is valid code according to jsm (only undefined at runtime). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug tree-optimization/17506] [4.0/4.1 regression] warning about uninitialized variable points to wrong location
--- Comment #33 from rguenth at gcc dot gnu dot org 2006-10-18 09:27 --- A backport bootstraps and regtests ok on the 4.1 branch. Don't know if the side-effects of this patch makes it appplicable for backporting though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug tree-optimization/29439] [4.2 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #13 from pluto at agmk dot net 2006-10-18 09:34 --- (In reply to comment #8) > The call int_const_binop to seems to be wrong, if the comment is correct the > following is more correct: > tree tmp = int_const_binop (TRUNC_DIV_EXPR, > res, > val1, 0); > with -fwrapv + this change, the a-stwifi.adb compiles, but other failure occurs later: a-stwiun.adb:34:06: warning: cannot depend on "Wide_Fixed" (wrong categorization) a-stwiun.adb:34:06: warning: preelaborated unit cannot depend on non-preelaborated unit a-stwiun.adb:34:17: warning: no entities of "Wide_Fixed" are referenced a-stwiun.adb:450:22: "Delete" not declared in "Wide_Fixed" a-stwiun.adb:555:20: "Head" not declared in "Wide_Fixed" a-stwiun.adb:567:22: "Head" not declared in "Wide_Fixed" a-stwiun.adb:695:22: "Insert" not declared in "Wide_Fixed" a-stwiun.adb:740:22: "Overwrite" not declared in "Wide_Fixed" a-stwiun.adb:758:26: "Overwrite" not declared in "Wide_Fixed" a-stwiun.adb:840:20: "Replace_Slice" not declared in "Wide_Fixed" a-stwiun.adb:853:20: "Replace_Slice" not declared in "Wide_Fixed" a-stwiun.adb:902:20: "Tail" not declared in "Wide_Fixed" a-stwiun.adb:913:20: "Tail" not declared in "Wide_Fixed" a-stwiun.adb:968:22: "Translate" not declared in "Wide_Fixed" a-stwiun.adb:977:17: "Translate" not declared in "Wide_Fixed" a-stwiun.adb:988:22: "Translate" not declared in "Wide_Fixed" a-stwiun.adb:997:17: "Translate" not declared in "Wide_Fixed" a-stwiun.adb:1011:22: "Trim" not declared in "Wide_Fixed" a-stwiun.adb:1022:22: "Trim" not declared in "Wide_Fixed" a-stwiun.adb:1036:22: "Trim" not declared in "Wide_Fixed" a-stwiun.adb:1049:22: "Trim" not declared in "Wide_Fixed" make[7]: *** [a-stwiun.o] Error 1 without this change and without -fwrapv bootstrap passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-10-18 09:43 --- Please attach a complete test case, not a sketch. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-18 09:46 --- Janis, can you check what fixed this on the mainline? Thanks! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Known to fail|4.1.1 |4.1.0 4.1.1 Last reconfirmed|2006-06-21 12:20:43 |2006-10-18 09:46:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug target/28132] [4.1 Regression] ICE instantiate_virtual_regs_in_insn when -fforce-addr -O1 used
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-18 09:49 --- I wonder what fixed this on the mainline - janis? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Known to fail|4.1.1 |4.1.0 4.1.1 Last reconfirmed|2006-06-22 09:26:22 |2006-10-18 09:49:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
[Bug tree-optimization/29439] [4.2 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-18 10:00 --- Well, this looks like a miscompilation somewhere then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #3 from pcarlini at suse dot de 2006-10-18 10:06 --- Let's suppose the issue is confirmed, and we have an useful complete testcase, then, a wild idea (at the moment I'm missing many details about the internals of the safe iterators, sorry): maybe we could explore the possibility to have the _M_invalidate functionality part of _Safe_iterator_base, thus easily use the debug mode mutex. I'm saying that because I'm under the impression that _M_invalidate basically uses info available in the _Safe_iterator_base. I'm only unsure about the tests "this->base() == __victim->base()", I hope can be done on the base objects too... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug fortran/29490] internal compiler error: in fold_binary, at fold-const.c:8239
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-18 10:08 --- (In reply to comment #2) > Thank you, Richard - thanks to your splendid analysis, I was able to go > straight to the source of the problem: > trans-types.c(gfc_get_nodesc_array_type):1038 sets GFC_TYPE_ARRAY_LBOUND to > NULL_TREE if the arrayspec lower is not constant. It then feeds through to > the > interfacery that cannot cope with this and the ICE ensues. There is no reason > why GFC_TYPE_ARRAY_LBOUND cannot be set; being fortran, gfc_index_one_node is > an OK choice, although zero does OK too. This is regtesting as I write. If > all is well, I will submit before going to bed. Hah! Famous last words... There is one g77 testcase that does not like this approach: g77/19981119-0.f Jumping past the offending build2 works fine; in fact the interface is not used at all, so I am wondering if there is not a cleaner way to do this. I will find a fix that I understand today. Paul Setting -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29490
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #4 from pcarlini at suse dot de 2006-10-18 10:40 --- (In reply to comment #3) > I'm > only unsure about the tests "this->base() == __victim->base()", I hope can be > done on the base objects too... And of course it can't, such simply, the plain iterator info is necessary here, because we want to change *all* iterators pointing the same as this->base()... In case, looks like _M_invalidate needs a more complex interaction between _Safe_iterator and _Safe_iterator_base... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug c++/26884] [4.1/4.2 regression] Misleading diagnostic for invalid array initializer
--- Comment #3 from shinwell at gcc dot gnu dot org 2006-10-18 10:57 --- Subject: Bug 26884 Author: shinwell Date: Wed Oct 18 10:57:18 2006 New Revision: 117854 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117854 Log: PR c++/26884 * typeck2.c (digest_init): Raise error upon attempts to initialize arrays with variables. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26884
[Bug c++/26884] [4.1/4.2 regression] Misleading diagnostic for invalid array initializer
--- Comment #4 from shinwell at gcc dot gnu dot org 2006-10-18 10:57 --- Subject: Bug 26884 Author: shinwell Date: Wed Oct 18 10:57:37 2006 New Revision: 117855 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117855 Log: PR c++/26884 * typeck2.c (digest_init): Raise error upon attempts to initialize arrays with variables. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26884
[Bug c++/26884] [4.1/4.2 regression] Misleading diagnostic for invalid array initializer
--- Comment #5 from shinwell at gcc dot gnu dot org 2006-10-18 10:58 --- Fixed in mainline and 4.1 (revs 117854 and 117855 respectively). -- shinwell at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26884
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #15 from irar at il dot ibm dot com 2006-10-18 11:03 --- (In reply to comment #13) > We need to check if above patch fixes PR26969 as well. Checked, it does not. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #9 from patchapp at dberlin dot org 2006-10-18 11:20 --- Subject: Bug number PR29216 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/2006-10/msg00900.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Comment #6 from pcarlini at suse dot de 2006-10-18 11:37 --- A straightforward approach to the problem uses the unsigned type associated with _Distance (via __gnu_cxx::__add_unsigned) to avoid the risk of overflows in __adjust_heap completely. I'm currently looking into the cleanest way to follow this route... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug c/448] -related issues (C99 issues)
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-18 12:31 --- The Fortran people are interested in this. For full F2003 support, we need the Fortran front-end to know during code generation which integer mode correspond to certain C integer types, including the int_fastN_t, intmax_t and size_t types. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-12-28 06:06:29 |2006-10-18 12:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #5 from matz at gcc dot gnu dot org 2006-10-18 14:04 --- The problem is in libcpp/files.c:open_file_failed. It deliberately only gives a warning when producing dependencies (and under some circumstances doesn't even give a warning) for missing files. I think it does that under the assumption that the user gave only -M (with -E implied), so he would be interested in the preprocessor output nevertheless, and that can be produced even with missing deps. The problem is, that giving -MD or -MMD does not imply -E, i.e. the user really wants the deps to just be a side-effect, as documented. Probably libcpp needs another option which can be set from the driver, which would make it produce errors instead of warnings. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug libgcj/29491] java.lang.InternalError: Pango: pango_color_parse: assertion `spec != NULL' failed
--- Comment #2 from dir at lanl dot gov 2006-10-18 14:37 --- This turned out to be a gtk bug - a rebuild of glib-2.12.4 followed by a rebuild of gtk+-2.10.6 fixed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29491
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #5 from grzes at nec-labs dot com 2006-10-18 14:40 --- I encountered this bug (?) in the past. I thought, maybe incorrectly, that accessing an interator (e.g copying it) equals read access to a container, hence no thread safety guarnatees for concurrent modifications to the container - like erase on another element. OTOH, this works fine in non-debug mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug c++/28053] [4.2 regression] ICE deriving from class with invalid bitfield
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-14 19:06:00 |2006-10-18 14:48:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28053
[Bug c++/28053] [4.2 regression] ICE deriving from class with invalid bitfield
--- Comment #3 from patchapp at dberlin dot org 2006-10-18 14:50 --- Subject: Bug number PR c++/28053 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/2006-10/msg00913.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28053
[Bug c++/29363] [4.2 regression] ICE throwing undeclared object
--- Comment #4 from patchapp at dberlin dot org 2006-10-18 15:00 --- Subject: Bug number PR c++/29363 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/2006-10/msg00914.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug other/28322] GCC new warnings and compatibility
--- Comment #2 from ian at davenant dot greenend dot org dot uk 2006-10-18 15:11 --- > Again this is a policy issue rather than really a bug, I am > thinking about closing this as invalid as I thought our policy is clear. I'm afraid I don't understand. What policy are you referring to ? It seems to me that better treatment of -Wno-this-is-not-a-recognised-warning is a no-brainer. If my specification is too complicated then simply ignoring unknown -Wno-* options would be a definite improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug testsuite/28829] FAIL: gcc.dg/pr26570.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-18 15:12 --- Subject: Bug 28829 Author: rguenth Date: Wed Oct 18 15:11:52 2006 New Revision: 117856 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117856 Log: 2006-10-18 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-08-25 Richard Guenther <[EMAIL PROTECTED]> PR testsuite/28829 * gcc.dg/pr26570.c: Fix testcase. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26570.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28829
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-18 15:56 --- Paolo: Seems like an interesting idea. Grzegorz: interesting that others have run into this. Without a testcase, it's hard to say with certainty what is valid and what is invalid. Also, without a testcase there are no certainties that if fixed, it remains fixed. Thus, why I'm insisting on a testcase. Care to give it a go? best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug debug/29436] [4.0/4.1/4.2 Regression] ICE in modified_type_die
--- Comment #11 from janis at gcc dot gnu dot org 2006-10-18 16:27 --- A regression hunt on powerpc-linux using the testcase from the submitter's description showed that it went from an ICE to an error with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=110925 r110925 | geoffk | 2006-02-13 21:17:59 + (Mon, 13 Feb 2006) Let me know if other reghunts would be useful here. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c++/29503] New: Internal Compiler Error with Friend + Template + Typedef
#define SSP_X_SMALL_POOL_SIZE 10
template < class ObjT, unsigned int uiInitialSize >
class ObjectFactory
{
public:
virtual ~ObjectFactory();
};
class TD{
public:
typedef ObjectFactory< TD, SSP_X_SMALL_POOL_SIZE > Factory;
public:
friend class TD::Factory;
}
Compiling the file with gcc gives :
New1.cpp:16: Internal compiler error.
New1.cpp:16: Internal compiler error:
New1.cpp:16: Please submit a full bug report.
Any Suggestions or workarounds.
--
Summary: Internal Compiler Error with Friend + Template + Typedef
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mangeshaj at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29503
[Bug libgomp/29494] [4.2 Regression] libgomp build fails with missing pthread_mutexattr_settype
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|trivial |normal Keywords||build Summary|libgomp build fails with|[4.2 Regression] libgomp |missing |build fails with missing |pthread_mutexattr_settype |pthread_mutexattr_settype http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug debug/29436] [4.0/4.1/4.2 Regression] ICE in modified_type_die
--- Comment #12 from geoffk at gcc dot gnu dot org 2006-10-18 17:08 --- Isn't this a dup of bug 28834? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug fortran/29497] Problem with preprocessor directive -x f95-cpp-input
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 17:08 --- This is working as designed, -x makes all input files as that type of file. -- 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=29497
[Bug c++/29503] Internal Compiler Error with Friend + Template + Typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 17:12 --- The ICE is fixed in 4.0.4 for sure: [EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gcc t.cc t.cc:16: error: using typedef-name TD::Factory after class t.cc:13: error: TD::Factory has a previous declaration here t.cc:18: error: expected unqualified-id at end of input [EMAIL PROTECTED] ~]$ ~/gcc-4.1/bin/gcc t.cc t.cc:16: error: using typedef-name TD::Factory after class t.cc:13: error: TD::Factory has a previous declaration here t.cc:18: error: expected unqualified-id at end of input [EMAIL PROTECTED] ~]$ ~/gcc-local/bin/gcc t.cc t.cc:16: error: using typedef-name TD::Factory after class t.cc:13: error: TD::Factory has a previous declaration here t.cc:18: error: expected unqualified-id at end of input You cannot friend a typedef at least not yet, there is a defect report about that in the C++ standard and another bug filed against GCC for it also but I cannot find it right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29503
[Bug debug/29436] [4.0/4.1/4.2 Regression] ICE in modified_type_die
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-18 17:19 --- (In reply to comment #12) > Isn't this a dup of bug 28834? Related for sure, dup unknown at this point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28834 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug other/29504] New: target header files are refrenced (or installed) in wrong location.
With newlib-1.13.0 TOOLDIR := /some/path/tools HOSTARCH := $(shell uname -p)-$(shell uname -s) TOOLARCHDIR := $(TOOLDIR)/arch/$(HOSTARCH) # On os-x TOOLARCHDIR == /some/patch/tools/arch/powerpc-Darwin # On linux TOOLARCHDIR == /some/patch/tools/arch/i686-Linux # On solaris TOOLARCHDIR == /some/patch/tools/arch/sparc-SunOS configure --with-newlib --enable-languages=c \ --prefix=$(TOOLDIR) --exec-prefix=$(TOOLARCHDIR) --target=ppc-elf \ --with-included-gettext \ --with-cpu=860 --enable-cxx-flags=-mcpu=860 after compiling things seem to work except when trying to compile a file for the target (no matter what the host) a file containing: #include the header is not found and when using the target cpp -v I find that the following warnings. ignoring nonexistent directory "/some/path/tools/arch/i686-Linux/lib/gcc/ppc-elf/3.4.6/../../../../../ppc-elf/sys-include" ignoring nonexistent directory "/some/path/tools/arch/i686-Linux/lib/gcc/ppc-elf/3.4.6/../../../../../ppc-elf/include" This would looks for the headers in arch.. but they are actually in arch/i686-Linux When I rolled back and did not use exec-prefix (just prefix) I found that the target cpp -v gave me: ignoring nonexistent directory "/some/path/tools/lib/gcc/ppc-elf/3.4.6/../../../../ppc-elf/sys-include" this missing path seems to cause no issues, or at least none that I can find. Another point... in the first case above it is looking in tools/arch/ppc-elf, when in fact the headers are installed in tools/arch/i686-Linux/ppc-elf.. shouldn't these be installed in tools/ppc-elf, since they should be the same for all host systems (Linux/Solaris/Darwin) since it's really the target (ppc-elf) that makes a diffrence? -- Summary: target header files are refrenced (or installed) in wrong location. Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jhanley at REDCOM dot com GCC host triplet: SunOS 5.10 sun4u, Linux 2.6.17-1.2157_FC5smp i686, Darwin 8.8.0 GCC target triplet: 860 ppc elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29504
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #4 from sje at cup dot hp dot com 2006-10-18 18:16 --- Looking at my old logs it looks like gfortran.dg/actual_array_constructor_1.f90 has been failing on hppa64 since it first went in on April 21, 2006. Someone is creating a TImode variable even though hppa64 doesn't support them. I haven't been able to figure out who though. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug target/3920] [PPC] wrong register number for CTR in stabs
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-10-18 18:41 --- The stabs numbering should probably match whatever AIX does. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk 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=3920
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-18 18:51 --- Subject: Re: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE) > Looking at my old logs it looks like > gfortran.dg/actual_array_constructor_1.f90 > has been failing on hppa64 since it first went in on April 21, 2006. Someone > is creating a TImode variable even though hppa64 doesn't support them. I > haven't been able to figure out who though. Right. I think figuring out who is creating the variable will help to understand and fix the bug. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug target/29498] FTZ/DAZ for SSE should be ported to mingw32
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 18:53 --- The fix is to move the including of "i386/t-crtfm" down to the i?86/x86_64 generic section instead of having it in the GNU/Linux section of config.gcc. -- 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 |2006-10-18 18:53:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
[Bug tree-optimization/16876] [4.0/4.1 Regression] ICE on testcase with -O3 in fold-const
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-10-18 18:56 --- (In reply to comment #17) > A backport of the patch bootstraps & regtests ok on the 4.1 branch. Except it introduces PR 29478. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||29478 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug libgcj/29491] java.lang.InternalError: Pango: pango_color_parse: assertion `spec != NULL' failed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-18 19:03 --- Closing as invalid then. -- 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=29491
[Bug fortran/29505] New: Should give an error when using: real :: r; r(j) = ...
The following program compiles in gfortran. I don't know how easily it could be detected, but defining a scalar and using it as an array should be detectable? For what it is worth: ifort also does not detect this error. Changing the "integer :: j = 1" into "integer :: j; j = 1" causes gfortran to emit an error: "Unexpected STATEMENT FUNCTION statement" (and also ifort now writes: "This name has not been declared as an array or a function.") program bug implicit none real :: del integer :: j = 1 del(j)=sin(10.0) print *, del(3) end -- Summary: Should give an error when using: real :: r; r(j) = ... Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-12 05:46:36 |2006-10-18 19:21:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
--- Comment #2 from patchapp at dberlin dot org 2006-10-18 19:36 --- Subject: Bug number PR c++/29022 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/2006-10/msg00940.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29503] Internal Compiler Error with Friend + Template + Typedef
--- Comment #2 from fang at csl dot cornell dot edu 2006-10-18 20:25 --- That would be PR 21498. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29503
[Bug fortran/29507] New: INDEX in an array initialization causes ICE
This code:
module z
character(8), parameter :: a(1:3)=(/'nint() ', 'log10() ', 'sqrt() '/)
integer, parameter :: b(1:3) = index(a, '(')
end module z
causes
troutmask:sgk[415] gfc4x -o z z.f90
z.f90:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:3470
--
Summary: INDEX in an array initialization causes ICE
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #6 from sje at cup dot hp dot com 2006-10-18 20:49 --- Well, I have tracked it back a little ways. gfc_trans_vla_type_sizes_1 calls gfc_trans_vla_one_sizepos with: gfc_trans_vla_one_sizepos (&TYPE_SIZE (type), body); If I print out type->type.size I see: gdb) p debug_tree(type->type.size) unit size align 128 symtab 0 alias set -1 precision 68 min max > side-effects invariant So I have a TImode here. How it got here, I don't yet know. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-18 20:49:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug fortran/29410] [Optimization] bug with TRANSFER() and -O2
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:50 --- Confirmed, and Andrew will soon have a patch for this. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [Optimization] bug with TRANSFER() and -O2
-- 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 |2006-10-18 20:50:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:52 --- (In reply to comment #6) > Since you are actively working on this, I have reassigned it to you. I hope > that's OK? It was OK, but I spent time looking at it and looking again, and I can't figure it out. Unassigning myself, sorry! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert 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=27900
[Bug fortran/29505] Should give an error when using: real :: r; r(j) = ...
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-18 20:52 --- Tobias, The code is valid fortran in that "del(j) = sin(10)" is a statement function. Putting any executable line before that line (such as j = 1) causes an error to be emitted. If you look at the -fdump-parse-tree you'll see symtree: del Ambig 0 symbol del (REAL 4)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS STATEMENT-PROC FUNCTION) value: -5.44021130e-1 result: del Formal arglist: j I think the bug should be closed as INVALID. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug fortran/16580] [4.1 only] gfortran ICE on test g77.f-torture/execute/intrinsic77.f
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59 --- Fixed on 4.2, won't backport to 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16580
[Bug fortran/29288] [4.1 only] All intrinsics are allowed as actual arguments
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59 --- Fixed on 4.2, won't backport to 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug fortran/29489] LBOUND (array) and LBOUND (array, DIM) give different results.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 21:02 --- Paul, I need to be Enlightened as to why the gfc_evaluate_now statements in your patch are needed here. If and when you have a little time, that is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug fortran/29505] Should give an error when using: real :: r; r(j) = ...
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-18 21:11 --- Yes, you are right. I somehow missed those. "12.5.4 Statement function A statement function is a function defined by a single statement. R1238 stmt-function-stmt is function-name ( [ dummy-arg-name-list ] ) = scalar-expr" -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug target/28132] [4.1 Regression] ICE instantiate_virtual_regs_in_insn when -fforce-addr -O1 used
--- Comment #5 from janis at gcc dot gnu dot org 2006-10-18 21:20 --- A regression hunt using the testcase and options from comment #2 with an i686-linux cross compiler identified the following patch which fixed the bug on mainline: http://gcc.gnu.org/viewcvs?view=rev&rev=114293 r114293 | sayle | 2006-06-01 01:37:17 + (Thu, 01 Jun 2006) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
[Bug fortran/24767] gfortran: -Wno-unused-label does not work properly
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-18 21:29 --- Fixed on trunk -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24767
[Bug middle-end/29299] [4.2 Regression] gcc "used" attribute has no effect on local-scope static variables
--- Comment #10 from hubicka at gcc dot gnu dot org 2006-10-18 21:40 --- Subject: Bug 29299 Author: hubicka Date: Wed Oct 18 21:39:52 2006 New Revision: 117863 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117863 Log: PR middle-end/29299 * cfgexpand.c (expand_used_vars_for_block): Vars marked used by user are used. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug java/29509] New: gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
Attached is the "make" output. I haven't had any luck getting a core dump -- "ulimit -c 0" can't be changed, no matter what I try. Any suggestions welcome. /eng/users/billt/gcc-4.1.1/host-powerpc-unknown-linux-gnu/gcc/gcj -B/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava/ -B/eng/users/billt/gcc-4.1.1/host-powerpc-unknown-linux-gnu/gcc/ -Wno-deprecated --encoding=UTF-8 --bootclasspath '' --classpath ..:/eng/users/billt/gcc-4.1.1/libjava:/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava:../../../../.././libjava/classpath:../../../../.././libjava/classpath/external/w3c_dom:../../../../.././libjava/classpath/external/sax:.: -C -d . -MD -MF lists/javax-swing-plaf.deps -MT lists/javax-swing-plaf.stamp -MP @lists/javax-swing-plaf.list ../../../../.././libjava/classpath/javax/swing/plaf/metal/MetalLookAndFeel.java: In class 'javax.swing.plaf.metal.MetalLookAndFeel': ../../../../.././libjava/classpath/javax/swing/plaf/metal/MetalLookAndFeel.java: In method 'javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(javax.swing.UIDefaults)': ../../../../.././libjava/classpath/javax/swing/plaf/metal/MetalLookAndFeel.java:775: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[7]: *** [lists/javax-swing-plaf.stamp] Error 1 make[7]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava/classpath/lib' make[6]: *** [compile-classes] Error 2 make[6]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava/classpath/lib' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava/classpath' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/eng/users/billt/gcc-4.1.1' make: *** [all] Error 2 $ gcc -v Reading specs from /usr/lib/gcc-lib/ppc-redhat-linux/2.95.3/specs gcc version 2.95.3 20010315 (release) -- Summary: gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: billt at tutsys dot com GCC build triplet: ppc-redhat-linux GCC host triplet: ppc-redhat-linux GCC target triplet: ppc-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug java/29509] gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 21:44 --- Can you try building with "make bootstrap" instead of make? If that works, then 2.95.3 has a bug which is miscompiling 4.1.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug fortran/29489] LBOUND (array) and LBOUND (array, DIM) give different results.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-18 21:50
---
Also, I should say, from my understanding the correct answer would be:
SIZE =0
LBOUND (soda, DIM) =1 1
LBOUND (soda) =1 1
UBOUND (soda, DIM) =0 2
UBOUND (soda) =0 2
And the difference (for the bounds with DIM arg specified) with what we
currently yield is due to my conditions in trans-intrinsic being stupidly
wrong:
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 117862)
+++ trans-intrinsic.c (working copy)
@@ -710,7 +710,7 @@
tree type;
tree bound;
tree tmp;
- tree cond, cond1, cond2, cond3, size;
+ tree cond, cond1, cond2, cond3, cond4, size;
tree ubound;
tree lbound;
gfc_se argse;
@@ -840,15 +840,21 @@
if (as)
{
tree stride = gfc_conv_descriptor_stride (desc, bound);
+
cond1 = fold_build2 (GE_EXPR, boolean_type_node, ubound, lbound);
cond2 = fold_build2 (LE_EXPR, boolean_type_node, ubound, lbound);
+
cond3 = fold_build2 (GT_EXPR, boolean_type_node, stride,
gfc_index_zero_node);
+ cond3 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3, cond1);
+ cond4 = fold_build2 (LT_EXPR, boolean_type_node, stride,
+ gfc_index_zero_node);
+ cond4 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond4, cond2);
+
if (upper)
{
- cond = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3, cond1);
- cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond2);
+ cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond3, cond4);
se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
ubound, gfc_index_zero_node);
@@ -862,9 +868,7 @@
else
cond = boolean_false_node;
- cond1 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3,
cond1);
- cond1 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond1, cond2);
-
+ cond1 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond3, cond4);
cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond1);
se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
--
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-18 21:50:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug middle-end/29299] [4.2 Regression] gcc "used" attribute has no effect on local-scope static variables
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-10-18 21:54 --- Patch for non-unit-at-a-time comitted now. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug fortran/29489] LBOUND (array) and LBOUND (array, DIM) give different results.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-18 22:05
---
Yet another bug found, yet another patch. I think this one is the last:
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 117862)
+++ trans-intrinsic.c (working copy)
@@ -710,7 +710,7 @@
tree type;
tree bound;
tree tmp;
- tree cond, cond1, cond2, cond3, size;
+ tree cond, cond1, cond2, cond3, cond4, size;
tree ubound;
tree lbound;
gfc_se argse;
@@ -840,15 +840,21 @@
if (as)
{
tree stride = gfc_conv_descriptor_stride (desc, bound);
+
cond1 = fold_build2 (GE_EXPR, boolean_type_node, ubound, lbound);
cond2 = fold_build2 (LE_EXPR, boolean_type_node, ubound, lbound);
+
cond3 = fold_build2 (GT_EXPR, boolean_type_node, stride,
gfc_index_zero_node);
+ cond3 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3, cond1);
+ cond4 = fold_build2 (LT_EXPR, boolean_type_node, stride,
+ gfc_index_zero_node);
+ cond4 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond4, cond2);
+
if (upper)
{
- cond = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3, cond1);
- cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond2);
+ cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond3, cond4);
se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
ubound, gfc_index_zero_node);
@@ -858,13 +864,11 @@
if (as->type == AS_ASSUMED_SIZE)
cond = fold_build2 (EQ_EXPR, boolean_type_node, bound,
build_int_cst (TREE_TYPE (bound),
- arg->expr->rank));
+ arg->expr->rank - 1));
else
cond = boolean_false_node;
- cond1 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3,
cond1);
- cond1 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond1, cond2);
-
+ cond1 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond3, cond4);
cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond1);
se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- Comment #9 from robert dot nagy at gmail dot com 2006-10-18 22:06 --- Hi. I'd like to backport the fix of this problem to OpenBSD because we still use gcc 3.3 here and we are not able to compile OpenOffice w/o fixing this. If someone can point me to the change you guys made I'd really appriciate it. Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-18 22:09 --- (In reply to comment #9) > If someone can point me to the change you guys made I'd really appriciate it. There have been too many changes to figure out what fixed this really and 3.3 is no longer being maintained by us. What most likely happened here is something changed the rtl which worked around the problem of the instruction scheduler blowing up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
[Bug java/29495] [ecj] some field & method flags not passed through
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-18 22:23 --- ... and also enum, synthetic, and annotation for Class -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-18 22:23:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29495
[Bug libgomp/29494] [4.2 Regression] libgomp build fails with missing pthread_mutexattr_settype
--- Comment #2 from rbrown at bravurasolutions dot com dot au 2006-10-18 22:54 --- (In reply to comment #1) > Right, bootstrap has been broken because of that for ages. > > I've pinged the patch many times but to no avail... > Eric's patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01300.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:13 --- Subject: Bug 29277 Author: jvdelisle Date: Wed Oct 18 23:13:33 2006 New Revision: 117866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117866 Log: 2006-10-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/29277 * io/write.c (write_a): Add conversion of LF to CR-LF for systems with #define HAVE_CRLF. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:23 --- Fixed on 4.2. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-18 23:36 --- Subject: Bug 28938 Author: tromey Date: Wed Oct 18 23:36:32 2006 New Revision: 117868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117868 Log: PR java/28938: * doc/install.texi (Prerequisites): Mention ecj1. (Configuration): Move --with-java-home to libgcj-specific section. Document --with-ecj-jar. Modified: branches/gcj-eclipse/gcc/ChangeLog branches/gcj-eclipse/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #6 from tromey at gcc dot gnu dot org 2006-10-18 23:37 --- Note that this isn't quite fixed yet, as we haven't documented how to handle gcjh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #2 from danglin at gcc dot gnu dot org 2006-10-19 01:04 --- I'm thinking this may have been caused by the emutls patch which was subsequently reverted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-19 01:56 --- Subject: Re: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE) > So I have a TImode here. How it got here, I don't yet know. I checked that pa_scalar_mode_supported_p is called and rejects TImode, so it looks like a fortran problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug rtl-optimization/26026] power of 2 mod missing optimisation
--- Comment #6 from bergner at gcc dot gnu dot org 2006-10-19 04:05 ---
Subject: Bug 26026
Author: bergner
Date: Thu Oct 19 04:05:34 2006
New Revision: 117877
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117877
Log:
* doc/invoke.texi: Add cpu_type power6x
(RS/6000 and PowerPC Options): Add -mmfpgpr.
* recog.c (store_data_bypass_p): Add support to allow IN_INSN to
be a PARALLEL containing sets. Return false when out_pat is not
a PARALLEL insn.
* config/rs6000/aix52.h (ASM_CPU_SPEC): Add power6x.
* config.gcc: Add cpu_type power6x.
* configure.ac: Add test for mf{t,f}gpr instructions.
(HAVE_AS_MFPGPR): New.
* config.in: Regenerate.
* configure: Regenerate.
* config/rs6000/linux64.h (PROCESSOR_DEFAULT): Default to POWER6.
(PROCESSOR_DEFAULT64): Likewise.
* config/rs6000/rs6000.md (define_attr "type"): Add insert_dword,
shift,trap,var_shift_rotate,cntlz,exts, var_delayed_compare, mffgpr
and mftgpr attributes.
(define_attr "cpu"): Add power6. Add power6x.
Change instruction sequences to use new attributes.
(floatsidf2,fix_truncdfsi2): use TARGET_MFPGPR.
(fix_truncdfsi2_internal_mfpgpr): New.
(floatsidf_ppc64_mfpgpr): New.
(floatsidf_ppc64): Added !TARGET_MFPGPR condition.
(movdf_hardfloat64_mfpgpr,movdi_internal64_mfpgpr): New.
(movdf_hardfloat64): Added !TARGET_MFPGPR condition.
(movdi_internal64): Added !TARGET_MFPGPR and related conditions.
(fix_truncdfsi2): Use gpc_reg_operand constraint.
* config/rs6000/{6xx.md,power4.md,8540.md,603.md,mpc.md,
7xx.md,rios2.md,7450.md,440.md,rios1.md,rs64.md,power5.md,40x.md}:
Add descriptions for insert_dword, shift,trap,var_shift_rotate,
cntlz,exts and var_delayed_compare.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
_ARCH_PWR6X, if features enabled.
* config/rs6000/rs6000.opt (mmfpgpr): New.
* config/rs6000/rs6000.c (rs6000_align_branch_targets): New variable.
(cached_can_issue_more): New variable.
(processor_costs): Add power6_cost.
(rs6000_sched_init): New function.
(is_dispatch_slot_restricted): Deleted.
(set_to_load_agen): New function.
(is_load_insn,is_store_insn): New functions.
(adjacent_mem_locations): New function.
(insn_must_be_first_in_group): New function.
(insn_must_be_last_in_group): New function.
(rs6000_sched_reorder): New function.
(rs6000_sched_reorder2): New function.
(TARGET_SCHED_INIT,TARGET_SCHED_REORDER,
TARGET_SCHED_REORDER2): Define.
(processor_target_table): Use PROCESSOR_POWER6 for power6.
Add power6x. Add MASK_MFPGPR for power6x.
(POWERPC_MASKS): Add MASK_MFPGPR.
(rs6000_override_options): Set rs6000_always_hint to false
for power6. Set rs6000_align_branch_targets. Replace
rs6000_sched_groups check with rs6000_align_branch_targets.
Use PROCESSOR_POWER6.
(last_scheduled_insn): New variable.
(load_store_pendulum): New variable.
(rs6000_variable_issue): Set last_scheduled_insn and
cached_can_issue_more.
(rs6000_adjust_cost): Add power6 cost adjustments.
(rs6000_adjust_priority): Replace is_dispatch_slot_restricted
with insn_must_be_first_in_group. Add power6 priority adjustments.
(rs6000_issue_rate): Add CPU_POWER6. Add CPU_POWER6X.
(insn_terminates_group_p): Use insn_must_be_{first,last}_in_group.
* config/rs6000/rs6000.h (processor_type): Add PROCESSOR_POWER6.
(TARGET_MFPGPR): New.
(SECONDARY_MEMORY_NEEDED): Use TARGET_MFPGPR.
(ASM_CPU_SPEC): Add power6x. Pass -mpower5 when cpu=power5.
Pass -mpower5 when cpu=power5+. Pass -mpower6 when cpu=power6.
(SECONDARY_MEMORY_NEEDED): Added mode!=DFmode and mode!=DImode
conditions.
* config/rs6000/power6.md: New file.
PR rtl-optimization/26026
Backport from mainline
2006-04-19 Alan Modra <[EMAIL PROTECTED]>
* fold-const.c (fold_binary): Optimize div and mod where the divisor
is a known power of two shifted left a variable amount.
Added:
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/power6.md
Modified:
branches/ibm/gcc-4_1-branch/gcc/ChangeLog
branches/ibm/gcc-4_1-branch/gcc/config.gcc
branches/ibm/gcc-4_1-branch/gcc/config.in
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/40x.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/440.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/603.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/6xx.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/7450.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/7xx.md
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/8540.md
branches/ibm/gcc-4_1-branc
[Bug libgomp/29494] [4.2 Regression] libgomp build fails with missing pthread_mutexattr_settype
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-10-19 04:49 --- > Eric's patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01300.html Right, but the info is already in the "Patch URL" field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #10 from pault at gcc dot gnu dot org 2006-10-19 04:51 --- Subject: Bug 29216 Author: pault Date: Thu Oct 19 04:51:14 2006 New Revision: 117879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117879 Log: 2006-10-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29216 PR fortran/29314 * gfortran.h : Add EXEC_INIT_ASSIGN. * dump-parse-tree.c (gfc_show_code_node): The same. * trans-openmp.c (gfc_trans_omp_array_reduction): Set new argument for gfc_trans_assignment to false. * trans-stmt.c (gfc_trans_forall_1): The same. * trans-expr.c (gfc_conv_function_call, gfc_trans_assign, gfc_trans_arrayfunc_assign, gfc_trans_assignment): The same. In the latter function, use the new flag to stop the checking of the lhs for deallocation. (gfc_trans_init_assign): New function. * trans-stmt.h : Add prototype for gfc_trans_init_assign. * trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN. * trans.h : Add new boolean argument to the prototype of gfc_trans_assignment. * resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by EXEC_INIT_ASSIGN. (resolve_code): EXEC_INIT_ASSIGN does not need resolution. (apply_default_init): New function. (resolve_symbol): Call it for derived types that become defined but which do not already have an initialization expression.. * st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN. 2006-10-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29216 * gfortran.dg/result_default_init_1.f90: New test. PR fortran/29314 * gfortran.dg/automatic_default_init_1.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Reduce deallocate count from 38 to 33. Added: trunk/gcc/testsuite/gfortran.dg/automatic_default_init_1.f90 trunk/gcc/testsuite/gfortran.dg/result_default_init_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug target/29314] misaligned FP register for VIS instructions
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-19 04:51 --- Subject: Bug 29314 Author: pault Date: Thu Oct 19 04:51:14 2006 New Revision: 117879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117879 Log: 2006-10-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29216 PR fortran/29314 * gfortran.h : Add EXEC_INIT_ASSIGN. * dump-parse-tree.c (gfc_show_code_node): The same. * trans-openmp.c (gfc_trans_omp_array_reduction): Set new argument for gfc_trans_assignment to false. * trans-stmt.c (gfc_trans_forall_1): The same. * trans-expr.c (gfc_conv_function_call, gfc_trans_assign, gfc_trans_arrayfunc_assign, gfc_trans_assignment): The same. In the latter function, use the new flag to stop the checking of the lhs for deallocation. (gfc_trans_init_assign): New function. * trans-stmt.h : Add prototype for gfc_trans_init_assign. * trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN. * trans.h : Add new boolean argument to the prototype of gfc_trans_assignment. * resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by EXEC_INIT_ASSIGN. (resolve_code): EXEC_INIT_ASSIGN does not need resolution. (apply_default_init): New function. (resolve_symbol): Call it for derived types that become defined but which do not already have an initialization expression.. * st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN. 2006-10-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29216 * gfortran.dg/result_default_init_1.f90: New test. PR fortran/29314 * gfortran.dg/automatic_default_init_1.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Reduce deallocate count from 38 to 33. Added: trunk/gcc/testsuite/gfortran.dg/automatic_default_init_1.f90 trunk/gcc/testsuite/gfortran.dg/result_default_init_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29314
[Bug c/29172] --combine can't handle #pragma once
--- Comment #2 from acahalan at gmail dot com 2006-10-19 05:28 --- Why is this still UNCONFIRMED, and why is it marked enhancement? The compiler is failing to follow the documented behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #11 from pault at gcc dot gnu dot org 2006-10-19 06:42 --- Fixed on trunk 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=29216
[Bug fortran/29394] Invalid derived-type initialization in function
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-19 06:42 --- Fixed on trunk 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=29394
