[Bug libfortran/21376] New: libfortran E output format causes FPE
There's an obvious bug in libfortran/io/write.c which causes a failure
to print 1.0 in exp. format - here's the fix:
diff -U3 -r gcc-4.0.0-old/libgfortran/io/write.c
gcc-4.0.0/libgfortran/io/write.c
--- gcc-4.0.0-old/libgfortran/io/write.c2005-04-05 15:24:36.0
+0100
+++ gcc-4.0.0/libgfortran/io/write.c2005-05-04 07:55:12.0 +0100
@@ -316,9 +316,11 @@
edigits = 2;
else
{
- edigits = 1 + (int) log10 (fabs(log10 (value)));
- if (edigits 2)
+ double absexp = fabs(log10 (value));
+ if (absexp 100)
edigits = 2;
+ else
+ edigits = 1 + (int) log10 (absexp);
}
if (ft == FMT_F || ft == FMT_EN
--
Summary: libfortran E output format causes FPE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prw at ceiriog1 dot demon dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,prw at ceiriog1 dot
demon dot co dot uk
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=21376
[Bug target/21297] [4.0 Regression] buf[i+i]=0 stores buf[i] when -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04 07:24 --- Subject: Bug 21297 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-04 07:24:34 Modified files: gcc: ChangeLog gcc/testsuite : ChangeLog gcc/config/i386: i386.c Added files: gcc/testsuite/gcc.c-torture/execute: 20050502-2.c Log message: PR target/21297 * config/i386/i386.c (legitimize_address): When canonicalizing ASHIFT into MULT, multiply by 1 shift_count instead of 1 log2 (shift_count). * gcc.c-torture/execute/20050502-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.214r2=2.7592.2.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.157r2=1.5084.2.158 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.795.6.6r2=1.795.6.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050502-2.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297
[Bug rtl-optimization/21239] [4.0 Regression] Illegal elimination of SSE2 load/store using xmm intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04 07:30 --- Subject: Bug 21239 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-04 07:29:29 Modified files: gcc: ChangeLog combine.c gcc/testsuite : ChangeLog gcc/config/i386: i386.c Added files: gcc/testsuite/gcc.dg: i386-sse-11.c Log message: * config/i386/i386.c (ix86_expand_vector_set): Fix setting 3rd and 4th item in V4SF mode. PR rtl-optimization/21239 * combine.c (combine_simplify_rtx) case VEC_SELECT: Fix a typo. * gcc.dg/i386-sse-11.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.215r2=2.7592.2.216 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.475.4.4r2=1.475.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.158r2=1.5084.2.159 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.795.6.7r2=1.795.6.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/i386-sse-11.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21239
[Bug middle-end/21265] [4.0 regression] GCC fails to optimize tail call to memset
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
07:36 ---
Subject: Bug 21265
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-04 07:35:32
Modified files:
gcc: ChangeLog builtins.c expr.h expr.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.dg: 20050503-1.c
Log message:
PR middle-end/21265
* expr.h (enum block_op_methods): Add BLOCK_OP_TAILCALL.
(clear_storage): Add argument.
* expr.c (emit_block_move_via_libcall, clear_storage_via_libcall):
Add tailcall argument, set CALL_EXPR_TAILCALL of the CALL_EXPR to
tailcall.
(emit_block_move): Handle BLOCK_OP_TAILCALL method.
(clear_storage): Add method argument, handle BLOCK_OP_TAILCALL.
(store_expr, store_constructor): Adjust callers.
* builtins.c (expand_builtin_memcpy): Pass BLOCK_OP_TAILCALL
to emit_block_move if CALL_EXPR_TAILCALL (exp).
(expand_builtin_memmove): Add ORIG_EXP argument, copy
CALL_EXPR_TAILCALL from ORIG_EXP to the new CALL_EXPR.
(expand_builtin_bcopy): Replace ARGLIST and TYPE arguments
with EXP. Pass EXP to expand_builtin_memmove.
(expand_builtin_memset): Add ORIG_EXP argument, pass
BLOCK_OP_TAILCALL to clear_storage if CALL_EXPR_TAILCALL (orig_exp).
(expand_builtin_bzero): Replace ARGLIST argument with EXP.
Pass EXP to expand_builtin_memset.
(expand_builtin_strcmp): Copy CALL_EXPR_TAILCALL from EXP to
the new CALL_EXPR.
(expand_builtin_strncmp): Likewise.
(expand_builtin_printf): Replace ARGLIST argument with EXP.
Copy CALL_EXPR_TAILCALL from EXP to the new CALL_EXPR.
(expand_builtin_fprintf): Likewise.
(expand_builtin): Adjust calls to
expand_builtin_{memmove,bcopy,memset,bzero,{,f}printf}.
* gcc.dg/20050503-1.c: New test.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.216r2=2.7592.2.217
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.426.2.1r2=1.426.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.186r2=1.186.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.778.6.1r2=1.778.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.159r2=1.5084.2.160
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050503-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21265
[Bug middle-end/21265] [4.0 regression] GCC fails to optimize tail call to memset
--- Additional Comments From giovannibajo at libero dot it 2005-05-04 08:14 --- Fixed, thanks Kaveh and Jakub! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21265
[Bug rtl-optimization/21239] [4.0 Regression] Illegal elimination of SSE2 load/store using xmm intrinsics
--- Additional Comments From giovannibajo at libero dot it 2005-05-04 08:15 --- Fixed, thanks Kurt for the report and Jakub for fixing it! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21239
[Bug target/21297] [4.0 Regression] buf[i+i]=0 stores buf[i] when -O2
--- Additional Comments From giovannibajo at libero dot it 2005-05-04 08:16 --- Fixed! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297
[Bug ada/21377] New: Error detected at a-stmaco.ads:65:4
While bootstrapping gcc-4.0.1 (20050503 pre) for sh-rtems4.7 using a native vanilla GCC-4.0.0 on FC3: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-stmaco.ads -o a-stmaco.o a-stmaco.ads: In function 'Ada.Strings.Maps.Constants._Elabs': a-stmaco.ads:40: error: unrecognizable insn: (insn:HI 98 97 99 1 a-stmaco.ads:68 (parallel [ (set (reg:HI 445) (ashift:HI (reg:HI 446) (reg:HI 447))) (clobber (reg:SI 147 t)) ]) -1 (insn_list:REG_DEP_TRUE 97 (nil)) (expr_list:REG_DEAD (reg:HI 447) (expr_list:REG_UNUSED (reg:SI 147 t) (expr_list:REG_EQUAL (ashift:HI (const_int 1 [0x1]) (reg:HI 447)) (nil) +===GNAT BUG DETECTED==+ | 4.0.0 (RTEMS gcc-4.0.0-20050503/newlib-1.13.0--0.rc.20050503.1.fc3) (sh-unknown-rtems4.7) GCC error:| | in extract_insn, at recog.c:2020 | | Error detected at a-stmaco.ads:65:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387 make[3]: *** [a-stmaco.o] Error 1 make[3]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada/rts' make[2]: *** [gnatlib] Error 2 make[2]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada' make[1]: *** [gnatlib-plain] Error 2 make[1]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/sh-rtems4.7/liba da' make: *** [all-target-libada] Error 2 -- Summary: Error detected at a-stmaco.ads:65:4 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com,laurent at guerby dot net GCC host triplet: i386-* GCC target triplet: sh-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug ada/21377] Error detected at a-stmaco.ads:65:4
-- What|Removed |Added Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 09:14 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | | Secondly, it is clear that your bug report is hypothetical. The | | library maintainers do not typically deal in hypotheticals. | I guess it is really a question of whether you want quality or | not. In general, all code is supposed incorrect until proven | otherwise -- in the case of threading issues, this is | particularly important, because of the random factors involved. | Of course, we want quality (and we want performance) which is | why we insist upon non-hypothetical bug reports (either way, | I've already explained what is wrong with your posted code | w.r.t. the cited FAQ entry) I know what was wrong with my code with regards to the FAQ. I know that the code didn't conform to *your* threading model. My point is that your threading model is, in a certain sense, wrong. It isn't what people expect, at least not people who are familiar with the Posix threading model. The documentation is in fact very misleading, with phrases like like for any other shared resource, when you don't need external synchronization for other shared resources, *unless* someone is actively modifying it. Now, I'm not saying that the Posix model is the only legitimate one. But it is the one I, and most people working on Unix platforms, are familiar with, and expect. And it is a standard on those platforms. You can choose to ignore it, and to ignore what SGI has done in this regard. But in that case, you have to be aware that you are trying to create an island, in which you are different from everyone else. | and why we insist that library users | must write correct locking sequences outside the context of the | library. As you well know, there is nothing in POSIX which | dictates that a library internalize the locking vs. implying | that the user code must hold a mutex lock. Posix only defines its own functions (most of which are either thread-safe, or have a thread-safe variant), and it only defines a binding for C for them. Other than that, we are left with general, language neutral statements like the one I quoted. Obviously, a library not specified by Posix can do what ever it wants. In practice, however, user expectations are based on what Posix does, and that leaves two alteratives: -- Model your library on the actual Posix functions, with full internal locking -- I can call write on the same file descriptor from two different threads, for example, without problems. A lot of people (although none of the experts I know) seem to expect this. Rogue Wave tries to do it, for example. IMHO, however, it isn't reasonable for a library which lets references (in the general sense) escape to the user -- Posix itself makes an exception for functions which return pointers to internal data structures. (It doesn't use those words, but if you look at the list of functions which are not guaranteed thread-safe, it includes exactly those functions, and no others.) -- Base your model on the general, language neutral statements. This is what SGI does, for example. The general statement is that I need a lock if more than one thread is accessing the memory, and any thread is modifying it. Since the abstraction model of C++ prevents me from actually seeing the memory, one is lead to exterpolate memory to object. This seems a reasonable interpretation to me. At least some experts agree -- the authors of the the SGI threading model, for example. (I consider the people who were working at SGI when that model was defined to be among the best threading experts in the world. That's just my opinion, but every time I've had a discussion with them, I've come out knowing more than when I went in.) You can, obviously, take the position that you have defined the threading model you wish to use, that you know better than everyone else, and that your decisions cannot be questioned. And I can take the position that you're just wrong, you don't know anything about threading, that g++ is worthless in a multithreaded environment, and publicize that opinion in various newsgroups. Such attitudes won't help either of us, however. This bug report came about because of a discussion in a news group. Basically, I said to watch out for std::string with g++ if you are in a multithreaded environment. I don't remember my exact words, but I'm pretty sure that the gist would have been that the g++ implementation of std::string does not behave as one might expect. I said it in a newsgroup, rather than making a bug report, because I knew of the text in the FAQ (or something similar), and I was convinced that no one here would consider it an error. Gaby suggested otherwise; that if I could describe a case where the code could fail, although no thread modified the string, I
[Bug rtl-optimization/18081] [3.4 regression] Infinite memory allocation on -O3
--- Additional Comments From gtolstolytkin at ru dot mvista dot com 2005-05-04 10:11 --- The bug is also exists in gcc-3.4-20050429 (gcc.3.4.4-preleleise). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug c++/21361] sizeof() packed structs potential errors
--- Additional Comments From moudekotte at khaeon dot nl 2005-05-04 10:27 --- I noticed the PCC_BITFIELD_TYPE_MATTERS setting (hint: http://www.astro.cf.ac.uk/cgi-bin/info2www?(gcc)Storage%20Layout ). I guess packing settings overrule this PCC_BITFIELD_TYPE_MATTERS setting? If it was meant to do so (and not just accidentally happened to do so), then please close this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21361
[Bug rtl-optimization/18081] [3.4 regression] Infinite memory allocation on -O3
--- Additional Comments From giovannibajo at libero dot it 2005-05-04 12:12 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00257.html Mark, is it OK to backport this patch to 3.4.4, with a proper ChangeLog? -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg00257.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-04 12:12 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string jkanze at cheuvreux dot com [EMAIL PROTECTED] writes: [...] | This bug report came about because of a discussion in a news | group. Basically, I said to watch out for std::string with g++ | if you are in a multithreaded environment. I don't remember my | exact words, but I'm pretty sure that the gist would have been | that the g++ implementation of std::string does not behave as | one might expect. I said it in a newsgroup, rather than making | a bug report, because I knew of the text in the FAQ (or | something similar), and I was convinced that no one here would | consider it an error. Gaby suggested otherwise; that if I could | describe a case where the code could fail, although no thread | modified the string, I should report it as a bug. So we're | here, and I'm getting hounded because my email contains trailers | which I can do nothing about:-). I was inordinately pleased by James -- I think you can abstract over the remark about your mailer, however annoying it is :-) As of the model behind the implementation of std::string, I do not think we have reached an agreement within the maintainers that it is actually right and your description is wrong. I'm of the opinion that we're reached a point where it causes so much conofusion that there must be something wrong with it. Having listening to either sides and looking at the codes, I'm inclined to consider your report valid -- however hypothetical my fellow maintainers may consider it :-) Concurrent read accesses should be guaranted, following POSIX. This is not because you're threatening to woersen g++'s reputation or disregard it in production use -- if it were that, I would not worry ;-). This is because no matter what we might say in our FAQ, if the behaviour is odd enough or singular enough, it entails Fear, Uncertainty and Doubt. That is not what we want. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched
--- Additional Comments From mustafa at il dot ibm dot com 2005-05-04 12:31 --- Is seems like this is not an SMS bug, sixtrack is failing for me with -m64 -O2 without -fmodulo-sched. Jania, have you checked that and have a different results? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21138
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 12:46 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | [...] | | This bug report came about because of a discussion in a news | | group. Basically, I said to watch out for std::string with g++ | | if you are in a multithreaded environment. I don't remember my | | exact words, but I'm pretty sure that the gist would have been | | that the g++ implementation of std::string does not behave as | | one might expect. I said it in a newsgroup, rather than making | | a bug report, because I knew of the text in the FAQ (or | | something similar), and I was convinced that no one here would | | consider it an error. Gaby suggested otherwise; that if I could | | describe a case where the code could fail, although no thread | | modified the string, I should report it as a bug. So we're | | here, and I'm getting hounded because my email contains trailers | | which I can do nothing about:-). I was inordinately pleased by | James -- | I think you can abstract over the remark about your mailer, however | annoying it is :-) I did put a smiley behind the complaint. I can imagine that all that garbage that gets added is as annoying to others as my being told to do something about it is to me. All I can say is that it annoys me too, and that Id get rid of it if I could. | As of the model behind the implementation of std::string, I do not | think we have reached an agreement within the maintainers that it is | actually right and your description is wrong. I'm of the opinion | that we're reached a point where it causes so much conofusion that | there must be something wrong with it. Having listening to either | sides and looking at the codes, I'm inclined to consider your report | valid -- however hypothetical my fellow maintainers may consider | it :-) Concurrent read accesses should be guaranted, following POSIX. All I really ask is that the problem be recognized. As I said, it only affects certain specific cases, and there are acceptable work arounds. If the doc says explicitly, we're doing something different here, I can live with that -- I would suppose that there were some good technical reasons (or possibly non-technical -- the world isn't 100% controlled by technology yet) for it. Responses along the lines of it's only hypothetical, or you're not playing the game according to our rules, are not helpful. They're not helpful because I know that already. The window of vulnerability is exceedingly small, which means that creating a test case which reliably fails is exceedingly difficult. From your comments in the newsgroup, I was fairly sure that you would accept my next best approach. From what I know of the extremely high technical competence of the other g++ developers, including the original author of std::string, I rather thought that they would, too. I'll admit that the hypothetical bit surprised me. The fact that I am not playing according to the official rules is another issue -- I know that, too, but I feel 1) that the official rules aren't really the best with regards to usability, and above all, 2) the way they are formulated is somewhat ingenious. Point 1 is, of course, personal opinion, but the fact that some experts are also led astray by the formulation is IMHO worth considering as a problem in itself. | This is not because you're threatening to woersen g++'s reputation | or disregard it in production use -- if it were that, I would not | worry ;-). That's because you know that the competition is Sun CC (which is no competition at all), and that I don't get to choose the compiler anyway:-). Seriously, however, I think you understand why I might feel obligated in certain contexts to mention the fact that g++ does have problems with regards to threading. Not problems like pre 3.0 had, of course, but the fact is that it doesn't always conform to the local conventions. Sometimes, for some very good reasons, but differences have to be doubly documented, because people don't expect them. | This is because no matter what we might say in our FAQ, | if the behaviour is odd enough or singular enough, it entails Fear, | Uncertainty and Doubt. That is not what we want. I think that's the key. People should feel at ease with the tool. Globally, I like g++ -- it's become my preferred compiler for most things. Which just makes me more upset about any weaknesses. (Like the absence of export, for example:-).) -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s)
[Bug c/21378] New: GCC Internal Compiler Error
When compiling a source file, GCC 4.0.0 exit with an Internal compiler error. This is the output of the `gcc -v` command: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --enable-cpp --enable-languages=c,c++,java --enable-interpreter --enable-java-net --with-x --with-java-awt=gtk,xlib --enable-nls --prefix=/usr Thread model: posix gcc version 4.0.0 This is the complete command line passed that triggers the bug: gcc -pipe -funsigned-char -march=athlon-xp -O3 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387 -msse -mmmx -m3dnow -Wno-unused-parameter -Wall -W -D_REENTRANT -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -DINTERNATIONAL -DFTGL_STATIC_LIBRARY -DNAN_BUILDINFO -Iintern/guardedalloc -I/home/mjordan/Blender/build/linux2/source/blender/blenlib -Isource/blender/blenlib -Isource/blender/blenlib -I/home/mjordan/Blender/build/linux2/source/blender/makesdna -Isource/blender/makesdna -Isource/blender/makesdna -I/home/mjordan/Blender/build/linux2/source/blender/blenkernel -Isource/blender/blenkernel -Isource/blender/blenkernel -I/home/mjordan/Blender/build/linux2/source/blender/include -Isource/blender/include -Isource/blender/include -Iintern/bmfont -I/home/mjordan/Blender/build/linux2/source/blender/imbuf -Isource/blender/imbuf -Isource/blender/imbuf -I/home/mjordan/Blender/build/linux2/source/blender/render/extern/include -Isource/blender/render/extern/include -Isource/blender/render/extern/include -Iintern/bsp/extern -I/home/mjordan/Blender/build/linux2/source/blender/renderconverter -Isource/blender/renderconverter -Isource/blender/renderconverter -I/home/mjordan/Blender/build/linux2/source/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Iintern/decimation/extern -I/home/mjordan/Blender/build/linux2/source/blender/blenloader -Isource/blender/blenloader -Isource/blender/blenloader -I/home/mjordan/Blender/build/linux2/source/blender/python -Isource/blender/python -Isource/blender/python -I/home/mjordan/Blender/build/linux2/source/kernel/gen_system -Isource/kernel/gen_system -Isource/kernel/gen_system -Iintern/SoundSystem -I/home/mjordan/Blender/build/linux2/source/blender/readstreamglue -Isource/blender/readstreamglue -Isource/blender/readstreamglue -I/home/mjordan/Blender/build/linux2/source/blender/img -Isource/blender/img -Isource/blender/img -I/home/mjordan/Blender/build/linux2/source/blender/quicktime -Isource/blender/quicktime -Isource/blender/quicktime -Iintern/ghost -Iintern/opennl/extern -I/usr/include/python2.3 -I/usr/include/SDL -I/usr/include -I/usr/X11R6/include -I/home/mjordan/Blender/build/linux2/source/blender/ftfont -Isource/blender/ftfont -Isource/blender/ftfont -c -o /home/mjordan/Blender/build/linux2/source/blender/src/editipo.o source/blender/src/editipo.c This is the output the compiler generates after that command line: source/blender/src/editipo.c: In function 'movekey_ipo': source/blender/src/editipo.c:4395: internal compiler error: in fold_convert, at fold-const.c:1922 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: GCC Internal Compiler Error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rperini at email dot it CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21378
[Bug c/21379] New: GCC Internal Compiler Error
When compiling a source file, GCC 4.0.0 exit with an Internal compiler error. This is the output of the `gcc -v` command: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --enable-cpp --enable-languages=c,c++,java --enable-interpreter --enable-java-net --with-x --with-java-awt=gtk,xlib --enable-nls --prefix=/usr Thread model: posix gcc version 4.0.0 This is the complete command line passed that triggers the bug: gcc -pipe -funsigned-char -march=athlon-xp -O3 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387 -msse -mmmx -m3dnow -Wno-unused-parameter -Wall -W -D_REENTRANT -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -DINTERNATIONAL -DFTGL_STATIC_LIBRARY -DNAN_BUILDINFO -Iintern/guardedalloc -I/home/mjordan/Blender/build/linux2/source/blender/blenlib -Isource/blender/blenlib -Isource/blender/blenlib -I/home/mjordan/Blender/build/linux2/source/blender/makesdna -Isource/blender/makesdna -Isource/blender/makesdna -I/home/mjordan/Blender/build/linux2/source/blender/blenkernel -Isource/blender/blenkernel -Isource/blender/blenkernel -I/home/mjordan/Blender/build/linux2/source/blender/include -Isource/blender/include -Isource/blender/include -Iintern/bmfont -I/home/mjordan/Blender/build/linux2/source/blender/imbuf -Isource/blender/imbuf -Isource/blender/imbuf -I/home/mjordan/Blender/build/linux2/source/blender/render/extern/include -Isource/blender/render/extern/include -Isource/blender/render/extern/include -Iintern/bsp/extern -I/home/mjordan/Blender/build/linux2/source/blender/renderconverter -Isource/blender/renderconverter -Isource/blender/renderconverter -I/home/mjordan/Blender/build/linux2/source/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Iintern/decimation/extern -I/home/mjordan/Blender/build/linux2/source/blender/blenloader -Isource/blender/blenloader -Isource/blender/blenloader -I/home/mjordan/Blender/build/linux2/source/blender/python -Isource/blender/python -Isource/blender/python -I/home/mjordan/Blender/build/linux2/source/kernel/gen_system -Isource/kernel/gen_system -Isource/kernel/gen_system -Iintern/SoundSystem -I/home/mjordan/Blender/build/linux2/source/blender/readstreamglue -Isource/blender/readstreamglue -Isource/blender/readstreamglue -I/home/mjordan/Blender/build/linux2/source/blender/img -Isource/blender/img -Isource/blender/img -I/home/mjordan/Blender/build/linux2/source/blender/quicktime -Isource/blender/quicktime -Isource/blender/quicktime -Iintern/ghost -Iintern/opennl/extern -I/usr/include/python2.3 -I/usr/include/SDL -I/usr/include -I/usr/X11R6/include -I/home/mjordan/Blender/build/linux2/source/blender/ftfont -Isource/blender/ftfont -Isource/blender/ftfont -c -o /home/mjordan/Blender/build/linux2/source/blender/src/editipo.o source/blender/src/editipo.c This is the output the compiler generates after that command line: source/blender/src/editipo.c: In function 'movekey_ipo': source/blender/src/editipo.c:4395: internal compiler error: in fold_convert, at fold-const.c:1922 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This is the complete output with the -v -save-temps flags added to the command line: gcc -v -save-temps -pipe -funsigned-char -march=athlon-xp -O3 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387 -msse -mmmx -m3dnow -Wno-unused-parameter -Wall -W -D_REENTRANT -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -DINTERNATIONAL -DFTGL_STATIC_LIBRARY -DNAN_BUILDINFO -Iintern/guardedalloc -I/home/mjordan/Blender/build/linux2/source/blender/blenlib -Isource/blender/blenlib -Isource/blender/blenlib -I/home/mjordan/Blender/build/linux2/source/blender/makesdna -Isource/blender/makesdna -Isource/blender/makesdna -I/home/mjordan/Blender/build/linux2/source/blender/blenkernel -Isource/blender/blenkernel -Isource/blender/blenkernel -I/home/mjordan/Blender/build/linux2/source/blender/include -Isource/blender/include -Isource/blender/include -Iintern/bmfont -I/home/mjordan/Blender/build/linux2/source/blender/imbuf -Isource/blender/imbuf -Isource/blender/imbuf -I/home/mjordan/Blender/build/linux2/source/blender/render/extern/include -Isource/blender/render/extern/include -Isource/blender/render/extern/include -Iintern/bsp/extern -I/home/mjordan/Blender/build/linux2/source/blender/renderconverter -Isource/blender/renderconverter -Isource/blender/renderconverter -I/home/mjordan/Blender/build/linux2/source/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Isource/blender/radiosity/extern/include -Iintern/decimation/extern -I/home/mjordan/Blender/build/linux2/source/blender/blenloader -Isource/blender/blenloader -Isource/blender/blenloader -I/home/mjordan/Blender/build/linux2/source/blender/python -Isource/blender/python -Isource/blender/python
[Bug c/21379] GCC Internal Compiler Error
--- Additional Comments From rperini at email dot it 2005-05-04 13:40 --- Created an attachment (id=8817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8817action=view) This is the preprocessed source file that triggers the bug This is the output generated with -v -save-temps flags -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21379
[Bug target/21377] Error detected at a-stmaco.ads:65:4
-- What|Removed |Added Component|ada |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs
--- Additional Comments From overholt at redhat dot com 2005-05-04 14:28 --- Any news here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
[Bug c/21380] New: ICE compiling with -O
When compiling the program below, gcc 4.0.0 dies with an ICE.
This also happens with gcc version 4.0.1 20050430 (prerelease)
gcc400 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/opt/gcc400
Thread model: posix
gcc version 4.0.0
command line:
gcc400 -O -c foo.c
program:
void bar (void);
void
foo (int *diff)
{
double deltay = 0.0;
int Stangent = 0;
int mindiff;
int Sflipped = 0;
int i;
int Sturn, Snofit;
Sturn = 1;
if (Sturn)
Stangent = 1;
if (Sturn)
{
Sflipped = 0;
Snofit = 1;
while (Snofit)
{
Snofit = 0;
mindiff = 0;
for (i = 0; i 4; i++)
mindiff = diff[i];
while (!Snofit (mindiff 0.0))
{
deltay = (Stangent ? deltay : 0.0);
if (deltay 0.0)
Snofit = 1;
for (i = 0; i 4; i++)
{
}
}
if (Snofit)
if (Sflipped)
break;
}
if (Snofit)
bar ();
}
}
--
Summary: ICE compiling with -O
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
[Bug middle-end/21378] GCC Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 14:31 --- Could you attach the preprocessed source as requested by the web site? -- What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21378
[Bug c/21379] GCC Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 14:32 --- *** Bug 21378 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21379
[Bug middle-end/21378] GCC Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 14:32 --- *** This bug has been marked as a duplicate of 21379 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21378
[Bug middle-end/21379] [4.0/4.1 Regression] GCC Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:53 ---
Confirmed, reduced testcase:
typedef struct IpoKey {
struct IpoKey *next, *prev;
short flag, rt;
float val;
struct BezTriple **data;
} IpoKey;
IpoKey *first;
static int float_to_frame (float frame)
{
int to= (int) frame;
if (frame-to0.5) to++;
return to;
}
int movekey_ipo(int dir, float scene)
{
IpoKey *ik;
float toframe = 0.0;
int a;
ik= first;
while (ik float_to_frame(ik-val)=(scene)) {
ik= ik-next;
}
if (ik) toframe= ik-val;
a= float_to_frame(toframe);
return a;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-05-04 14:53:10
date||
Summary|GCC Internal Compiler Error |[4.0/4.1 Regression] GCC
||Internal Compiler Error
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21379
[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 14:55 --- Confirmed, backtrace: #0 0x00112d98 in thread_block (bb=0x41485570) at /Users/pinskia/src/gcc-4.0/gcc/gcc/tree-ssa- threadupdate.c:503 #1 0x00112eb8 in thread_through_all_blocks () at /Users/pinskia/src/gcc-4.0/gcc/gcc/tree-ssa- threadupdate.c:565 #2 0x000ef914 in tree_ssa_dominator_optimize () at /Users/pinskia/src/gcc-4.0/gcc/gcc/tree-ssa- dom.c:437 -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, law at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-05-04 14:55:44 date|| Summary|ICE compiling with -O |[4.0 Regression] ICE ||compiling with -O Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs
--- Additional Comments From ziga dot mahkovec at klika dot si 2005-05-04 15:01 --- My copyright papers were resent and arrived successfully this time. This was about a week ago (and I returned them immediately) so I expect the confirmation Real Soon Now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
[Bug fortran/21381] New: Internal compiler error: in set_value_range
Compiling this code (AMD64 under SuSE Linux Professional 9.1): SUBROUTINE OPTBUG(N,A,LDA,B,LDB) C .. Scalar Arguments .. INTEGER LDA, LDB, N C .. Array Arguments .. REALA(LDA,N), B(LDB,N) C .. Local Scalars .. REALA1 INTEGER I, J C .. Executable Statements .. DO 40 J = 1, N DO 20 I = 1, J A1 = A(I,J) B(I,J) = A1 20 CONTINUE 40 CONTINUE RETURN END with optimization level -O2 or above, like this: gfortran -v -Wall -O2 -c optbug.f gives the following error message: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20050422/irun --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050422 (experimental) /opt/gfortran/irun/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.1.0/f951 optbug.f -ffixed-form -quiet -dumpbase optbug.f -mtune=k8 -auxbase optbug -O2 -Wall -version -o /tmp/ccGwsoUd.s GNU F95 version 4.1.0 20050422 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 optbug.f: In function optbug: optbug.f:1: internal compiler error: in set_value_range, at tree-vrp.c:124 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Internal compiler error: in set_value_range Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mick at nag dot co dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21381
[Bug tree-optimization/21381] Internal compiler error: in set_value_range
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 15:05 --- *** This bug has been marked as a duplicate of 21030 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|fortran |tree-optimization Keywords||ice-on-valid-code Resolution||DUPLICATE Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21381
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 15:05 --- *** Bug 21381 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mick at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug other/21382] New: -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build.
on both archs shared objects are build with: -O2 -ggdb -fvisibility-inlines-hidden -fPIC -DPIC linking fails with an error: /usr/bin/ld: .libs/IexBaseExc.o: relocation R_X86_64_PC32 against `_ZNSsD1Ev@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value without -fvisiblity-inlines-hidden everything is ok on all archs. is this a gcc or binutils bug? # gcc-4.0.0 (+fixes for PRs 20973,21173) # binutils-2.16.90.0.2 -- Summary: -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at pld-linux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: amd64 ppc GCC host triplet: amd64 ppc GCC target triplet: amd64 ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
[Bug other/21382] -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build.
--- Additional Comments From pluto at pld-linux dot org 2005-05-04 15:08 --- Created an attachment (id=8818) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8818action=view) build log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
[Bug other/21382] -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build.
--- Additional Comments From pluto at pld-linux dot org 2005-05-04 15:08 --- Created an attachment (id=8819) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8819action=view) build log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O
--- Additional Comments From law at redhat dot com 2005-05-04 15:10 --- Subject: Re: [4.0 Regression] ICE compiling with -O On Wed, 2005-05-04 at 14:56 +, pinskia at gcc dot gnu dot org wrote: If you want, go ahead and assign this to me... Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
[Bug other/21382] -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build.
-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
[Bug middle-end/21379] [4.0/4.1 Regression] GCC Internal Compiler Error
--- Additional Comments From rperini at email dot it 2005-05-04 15:13 --- (In reply to comment #2) *** Bug 21378 has been marked as a duplicate of this bug. *** Sorry for double posting. I have some problems on my Internet connection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21379
[Bug c++/21383] New: Crash when finding a_templated_func
Crash when finding a_templated_func. I realize that that's not valid
code, so I expected I diagnostic, but I got an ICE instead.
Here's the command line:
panacea g++ -v -save-temps /tmp/gccbug.cc
Reading specs from /usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/gcc-3.4.3 --enable-l
anguages=c,c++,f77
Thread model: posix
gcc version 3.4.3
/usr/local/gcc-3.4.3/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -E -quiet -v -
D_GNU_SOURCE /tmp/gccbug.cc -mtune=pentiumpro -o gccbug.ii
ignoring nonexistent directory /usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3
.4.3/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3
/usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3/i686-pc-linux-gnu
/usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3/backward
/usr/local/include
/usr/local/gcc-3.4.3/include
/usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
/usr/local/gcc-3.4.3/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -fpreprocessed
gccbug.ii -quiet -dumpbase gccbug.cc -mtune=pentiumpro -auxbase gccbug -version
-o gccbug.s
GNU C++ version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.2.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/tmp/gccbug.cc: In function `int main()':
/tmp/gccbug.cc:13: 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.
And here is the preprocessed source code:
# 1 /tmp/gccbug.cc
# 1 built-in
# 1 command line
# 1 /tmp/gccbug.cc
template class T
void dummy(T t)
{}
void anyfunc(int x)
{}
int main()
{
anyfunc(dummy);
}
--
Summary: Crash when finding a_templated_func
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mahall at ncsa dot uiuc dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug c++/21383] Crash when finding a_templated_func
--- Additional Comments From mahall at ncsa dot uiuc dot edu 2005-05-04 16:11 --- Oh - the address_of operator is not necessary - the crash occurs if we use just anyfunc(dummy); -matt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug rtl-optimization/18081] [3.4 regression] Infinite memory allocation on -O3
--- Additional Comments From mark at codesourcery dot com 2005-05-04 16:33 --- Subject: Re: [3.4 regression] Infinite memory allocation on -O3 giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-05-04 12:12 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00257.html Mark, is it OK to backport this patch to 3.4.4, with a proper ChangeLog? Yes, with proper testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug libfortran/21376] libfortran E output format causes FPE
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-04 16:41 --- I'm interested: you do have a testcase that produces this failure on i686-pc-linux-gnu? If so, I will make a testcase out of it and propose your patch for review... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21376
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 16:55 --- One other note. Shouldn't the segfault in _Jv_Linker be fixed anyway? Dereferencing a point of value 0x01 isn't likely to be valid in any circumstances? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding a_templated_func
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 17:02 --- Confirmed, here is the backtrace: #0 arg_assoc_args (k=0xbff447d4, args=0xb7c68f30) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/cp/name-lookup.c:4434 #1 0x08151dfa in lookup_arg_dependent (name=0xb7c8b23c, fns=0xb7c8c654, args=0xb7c68f30) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/name-lookup.c:4484 #2 0x08131d50 in perform_koenig_lookup (fn=0xff, args=0xb7c68f30) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/semantics.c:1711 #3 0x080ef88e in cp_parser_unary_expression (parser=0xb7c8b2a4, address_p=0 '\0', cast_p=0 '\0') at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:4108 #4 0x080f01f2 in cp_parser_assignment_expression (parser=0xb7c8b2a4, cast_p=0 '\0') at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:5413 #5 0x080f1999 in cp_parser_expression (parser=0xb7c8b2a4, cast_p=Variable cast_p is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:5717 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-05-04 17:02:56 date|| Summary|Crash when finding |[3.4/4.0/4.1 Regression] |a_templated_func |Crash when finding ||a_templated_func Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug other/21382] -fvisibility-inlines-hidden breaks OpenEXR-1.2.2 build.
--- Additional Comments From hjl at lucon dot org 2005-05-04 17:15 --- Known gcc bug. Check out my patch in bug 19664: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html You may need to fix libstdc++ header files also. *** This bug has been marked as a duplicate of 19664 *** -- What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-05-04 17:15 --- *** Bug 21382 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |law at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
[Bug rtl-optimization/18081] [3.4 regression] Infinite memory allocation on -O3
--- Additional Comments From giovannibajo at libero dot it 2005-05-04 17:19 --- Greg, mind testing this also with a bootstrap on x86-linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug driver/21112] [3.4/4.0/4.1 Regression] Xassembler and Xpreprocessor does not worked
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04 17:20 --- Subject: Bug 21112 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-04 17:20:44 Modified files: gcc: ChangeLog gcc.c Log message: Fix the Xassembler and Xpreprocessor options, which have never worked right. PR driver/21112 * gcc.c (process_command): In the second argv scan loop, ignore Xassembler and Xpreprocessor, along with their argument. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8599r2=2.8600 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gccr1=1.456r2=1.457 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21112
[Bug libfortran/21376] libfortran E output format causes FPE
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-05-04 17:28 ---
The problem occurred in a large finite element analysis code I developed.
The toplevel logic was written in C++, and this was linked to a venerable
public domain numerical analysis library in Fortran. My testcase consists
of the following two files. You only get a floating point exception
if IEEE floating point exceptions are enabled. I don't know if it is possible
to do this from a pure Fortran program, but it is certainly possible to
do from C, and I find it important to do this in numerical codes so that
I can see errors where they occur rather than just propagating NaN's through
the program.
File toplevel.c:
#include fenv.h
main()
{
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
killer_();
}
File killer.f:
subroutine killer
write(6,'(x,e10.4)') 1.0
end
gcc -c toplevel.c
gfortran -c killer.f
gcc toplevel.o killer.o -lgfortran
./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21376
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
--- Additional Comments From bkonrath at redhat dot com 2005-05-04 17:45 --- Daniel, could you post the actual source for those classes? Thanks, Ben -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug fortran/21384] New: internal compiler error: Bus error
Unaligned COMMON blocks generate bus erros. One of the most basic test used by configure to test the alignement of the Fortran types fail to compile. Even worst it generate a bus error on an Apple computer. program falign external ALIGN LOGICAL w,x,y,z CHARACTER a,b,c common /foo/a,w,b,x,y,c,z call ALIGN(w,x,y,z) end gfortran has been compiled from snapshot download today (4 May 2005) from the gcc website. I compile it on a dual G5 machine using the flags -mcpu=G5 -maltivec. -- Summary: internal compiler error: Bus error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gbosilca at utk dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.0.0 GCC host triplet: powerpc-apple-darwin8.0.0 GCC target triplet: powerpc-apple-darwin8.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21384
[Bug fortran/21384] internal compiler error: Bus error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:00 --- I thought this was fixed. on i686-pc-linux-gnu we get the following warnings: In file t.f:7 common /foo/a,w,b,x,y,c,z 1 Warning: Padding of 3 bytes required before 'x' in COMMON 'foo' at (1) In file t.f:7 common /foo/a,w,b,x,y,c,z 1 Warning: Padding of 3 bytes required before 'z' in COMMON 'foo' at (1) In file t.f:7 common /foo/a,w,b,x,y,c,z 1 Warning: COMMON 'foo' at (1) requires 3 bytes of padding at start Guess I have to check on my Mac OS X box when I get back to my dorm room. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21384
[Bug c++/21385] New: __extension__ lost inside template
Target: x86_64-suse-linux
Configured with: ../gcc-4.0.0/configure --prefix=/ita3 --enable-languages=c,c++
--with-system-
zlib --enable-__cxa_atexit x86_64-suse-linux : (reconfigured)
../gcc-4.0.0/configure --prefix=/ita3
--enable-languages=c,c++ --with-system-zlib --enable-__cxa_atexit
--disable-checking x86_64-
suse-linux
Thread model: posix
gcc version 4.0.0
template functions appear to erase the effect of the __extension__ keyword
inside their definitions,
causing -ansi -pedantic to produce an error instead of a warning.
Compiling the following code with -ansi -pedantic produces an error for the
line in the template
function, but not the ordinary function.
% g++ -c -ansi -pedantic foo.cpp
foo.cpp: In function âint template_function(int) [with T = void]â:
foo.cpp:15: instantiated from here
foo.cpp:11: error: ISO C++ forbids variable-size array
--
int ordinary_function(int dimension)
{
__extension__ int data[dimension];
return 0;
}
templatetypename T
int template_function(int dimension)
{
__extension__ int data[dimension];
return 0;
}
template int template_functionvoid(int);
--
Summary: __extension__ lost inside template
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jimrees at itasoftware dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21385
[Bug c++/21385] __extension__ lost inside template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:10 --- Confirmed, not a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||rejects-valid Known to fail||2.95.3 3.0.4 3.3.3 3.4.0 ||4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-05-04 18:10:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21385
[Bug middle-end/18908] Missed folding opportunities with bools
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:15 --- f2 is now fixed. -- What|Removed |Added GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:19 --- I think this is fixed on the mainline, for x86, in 4.0.0 we get: movl4(%esp), %edx testl %edx, %edx je .L2 leal-1(%edx), %eax xorl%ecx, %ecx testl %eax, %edx jne .L5 .L2: movl$1, %ecx .L5: movl%ecx, %eax ret But on the mainline we get: movl4(%esp), %edx movl$1, %eax testl %edx, %edx je .L4 leal-1(%edx), %eax testl %eax, %edx sete%al movzbl %al, %eax .L4: ret -- What|Removed |Added GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | GCC target triplet|alphaev68-unknown-linux-gnu |alphaev68-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug c++/21386] New: Inconsistent diagnostics for taking address of rvalue
g++ reports an error where a program attempts to take the address of an rvalue
of built-in type, but merely warns where it takes the address of an rvalue of
user-defined type:
$ cat test.cc
int i() { return 0; }
class A {};
A a() { return A(); }
int main()
{
int * pi = i();
A * pa = a();
}
$ g++-3.4 test.cc
test.cc: In function `int main()':
test.cc:6: error: non-lvalue in unary `'
test.cc:7: warning: taking address of temporary
The first error message is also odd; non-lvalue is C terminology that is
rarely used in relation to C++.
I would expect an attempt to take the address of an rvalue of any type to result
in an error; it's banned by the standard and I can't think of any useful
semantics for it if it is allowed.
--
Summary: Inconsistent diagnostics for taking address of rvalue
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benh at bwsint dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21386
[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:34 --- (In reply to comment #0) The first error message is also odd; non-lvalue is C terminology that is rarely used in relation to C++. That is wrong because the standard actually uses lvalue and rvalue all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21386
[Bug driver/21112] [3.4/4.0/4.1 Regression] Xassembler and Xpreprocessor does not worked
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04 18:42 --- Mine. Andrew Pinski claims Xpreprocessor was in gcc-3.3.3 and works, but I can find no evidence to support that. It does not show up in a grep of FSF gcc-3.3.x sources. Also, the original patch that added Xassembler also added Xpreprocessor, so I do not see how one could have existed before the other. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-04-19 20:54:06 |2005-05-04 18:42:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21112
[Bug driver/21112] [3.4/4.0/4.1 Regression] Xassembler and Xpreprocessor does not worked
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04 18:51 --- Fixed on mainline. I do not believe that there is any regression here, and hence I do not believe that the patch needs to be applied to the gcc-3.4 or gcc-4.0 branches. I'll leave this open for now in case anyone wants to disagree with me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21112
[Bug driver/21112] Xassembler and Xpreprocessor does not worked
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 18:51 --- (In reply to comment #3) Mine. Woops I was wrong, I was looking at it wrongly. I must have missed the warning: gcc: unrecognized option `-Xpreprocessor' -- What|Removed |Added Known to work|3.3.3 | Summary|[3.4/4.0/4.1 Regression]|Xassembler and Xpreprocessor |Xassembler and Xpreprocessor|does not worked |does not worked| Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21112
[Bug c++/21387] New: Unaligned writes on MIPSEL systems after typecast
See code below. After type-casting, the compiler incorrectly assumes that
'a.unaligned_int' is aligned on a word boundary. On a MIPSEL system (here a
Cobalt RaQ 2) a 'sw' assembler instruction is generated to store the value in
memory, resulting in a 'Segmentation fault'. Changing the 'sw' instruction to
'swl', the problem is solved.
#include stdint.h
#pragma pack(1)
typedef struct {
int8_t byte;
int32_t unaligned_int;
} test_unaligned;
#pragma pack()
int main(int argc, char *argv[]) {
test_unaligned a;
*((int32_t *) a.unaligned_int) = 0x123456;
return(0);
}
--
Summary: Unaligned writes on MIPSEL systems after typecast
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maarten at contemplated dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: mipsel-netbsd2.0
GCC host triplet: mipsel-netbsd2.0
GCC target triplet: mipsel-netbsd2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21387
[Bug target/21387] Unaligned writes on MIPSEL systems after typecast
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 19:10 --- I think this is invalid because the standard talks about alignment and types. -- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21387
[Bug other/21388] New: gcov-io.h compilation warning
This patch http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01484.html causes ./xgcc -B./ -B/usr/gcc-3.4/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-3.4/x 86_64-unknown-linux-gnu/include -isystem /usr/gcc-3.4/x86_64-unknown-linux-gnu/s ys-include -L/export/build/gnu/gcc-3.4/build-x86_64-linux/gcc/../ld -O2 -DIN_GC C-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-sty le-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D_ _GCC_FLOAT_NOT_NEEDED -I. -I -I/net/gnu/export/gnu/src/gcc-3.4/gcc/gcc -I/net/g nu/export/gnu/src/gcc-3.4/gcc/gcc/ -I/net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/../ include -DL_gcov -c /net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/libgcov.c -o libgc c/./_gcov.o In file included from /net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/gcov-io.h:240, from /net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/libgcov.c:51: ./auto-host.h:185:1: warning: HAVE_DECL_GETOPT redefined In file included from /net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/libgcov.c:37: /net/gnu/export/gnu/src/gcc-3.4/gcc/gcc/tsystem.h:40:1: warning: this is the loc ation of the previous definition -- Summary: gcov-io.h compilation warning Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org,janis187 at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21388
[Bug fortran/21384] internal compiler error: Bus error
--- Additional Comments From gbosilca at utk dot edu 2005-05-04 19:24 --- I get the latest version from CVS. And the bug seems to be fixed on this version. fortran compiler version: applebasket:/tmp root# gfortran --version GNU Fortran 95 (GCC 4.1.0 20050504 (experimental)) Copyright (C) 2005 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Result of the code: In file check_size.F:5 common /foo/a,w,b,x,y,c,z 1 Warning: Padding of 3 bytes required before 'x' in COMMON 'foo' at (1) In file check_size.F:5 common /foo/a,w,b,x,y,c,z 1 Warning: Padding of 3 bytes required before 'z' in COMMON 'foo' at (1) In file check_size.F:5 common /foo/a,w,b,x,y,c,z 1 Warning: COMMON 'foo' at (1) requires 3 bytes of padding at start -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21384
[Bug fortran/21384] internal compiler error: Bus error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 19:30 --- Lets reopen it and ... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21384
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 19:31 --- *** Bug 21384 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||gbosilca at utk dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug fortran/21384] internal compiler error: Bus error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 19:31 --- Close it as a dup of bug 20059. *** This bug has been marked as a duplicate of 20059 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21384
[Bug c/21389] New: optimized code seg faults due to double load on sparcV9
When -O3 or higher is used, the optimizer utilizes the lddf sparc instruction to load doubles into registers. This can generate a bus-error/seg-fault at runtime if the source address of the load is not mod8. The optimizer does not check this, even with -munaligned-doubles set. -- Summary: optimized code seg faults due to double load on sparcV9 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drew dot johnson at andrew dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 3.4.2 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
[Bug c/21389] optimized code seg faults due to double load on sparcV9
--- Additional Comments From drew dot johnson at andrew dot com 2005-05-04 19:38 --- Created an attachment (id=8820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8820action=view) compile with -O3 or higher, and execution generates seg-fault The included file compiles with just -O3 or higher as arguments. It should run and print a bunch of lines to stdout, then exit normally. When compiled at -O3 or higher, it generates a bus-error on the command line, due to a segmentation violation signal when run from the debugger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
[Bug driver/21112] Xassembler and Xpreprocessor does not worked
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04 19:39 --- Since everyone agrees there is no regression, I am closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Known to work||4.1.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21112
[Bug middle-end/21006] [4.1 Regression] g++.dg/other/static11.C fails
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-04 19:40 --- Appears to have started passing again (on hppa2.0w-hpux, hppa64-hpux, i686-linux, ia64-hpux at least) between 20050503 and 20050504. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21006
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 19:48 --- Okay, after fixing some makefile bugs, the workaround suggested by Tom worked. Feel free to close this now unless you want to track down the SIGSEGV. Reid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug target/21389] optimized code seg faults due to double load on sparcV9
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
[Bug regression/21390] New: alphaev68-dec-osf5.1b long double optimization bug with gcc-4.0.0
/*
alphaev68-dec-osf5.1b long double optimization bug with gcc-4.0.0
regression from gcc-3.4.3
% config.guess
alphaev68-dec-osf5.1b
% gcc -v
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with: /usr/local/gcc-4.0.0/src/gcc-4.0.0/configure
--enable-languages=c --prefix=/usr/local/gcc-4.0.0/alpha-OSF1-V5
Thread model: posix
gcc version 4.0.0
%
% gcc -mieee-with-inexact -o foo foo.c
% foo
1
%
% gcc -mieee-with-inexact -O1 -o foo foo.c
% foo
0
%
only happens with long double, not with double
*/
#include stdio.h
#define DBL_NAN ((long double) 0.0/0.0)
static int
Isnan_ld (long double d)
{
int ans;
long double __x = (d);
if ((d) != __x)
ans = 1;
else
ans = 0;
return ans;
}
int
main (int argc, char *argv[])
{
long double d;
d = (long double) DBL_NAN;
printf(%d\n, Isnan_ld(d));
return 0;
}
--
Summary: alphaev68-dec-osf5.1b long double optimization bug with
gcc-4.0.0
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kminola at eng dot umd dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alphaev68-dec-osf5.1b
GCC host triplet: alphaev68-dec-osf5.1b
GCC target triplet: alphaev68-dec-osf5.1b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21390
[Bug middle-end/21006] [4.1 Regression] g++.dg/other/static11.C fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 20:07 --- Fixed by: 2005-05-03 Richard Henderson [EMAIL PROTECTED] * cfg.c (dump_flow_info): Use max_reg_num, not max_regno. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21006
[Bug target/21390] alphaev68-dec-osf5.1b long double optimization bug with gcc-4.0.0
-- What|Removed |Added Component|regression |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21390
[Bug tree-optimization/19790] equality not noticed when signedness differs.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 20:31 --- We get: i_3 = i_6 + 1; bar (i_3); D.1284_20 = (unsigned int) i_3; i.0_25 = D.1284_20 + 0; D.1241_5 = i.0_25 5; D.1242_10 = D.1241_5 * 4; D.1243_11 = (int *) D.1242_10; D.1244_12 = array_8 + D.1243_11; D.1245_13 = *D.1244_12; D.1246_14 = (long unsigned int) D.1245_13; D.1247_15 = i_6 31; D.1248_16 = 1 D.1247_15; D.1249_17 = D.1246_14 | D.1248_16; D.1250_18 = (int) D.1249_17; *D.1244_12 = D.1250_18; Now, which is semi better in that there is no extra cast but there is still a -1 issue, i.0_25 = (unsigned) i_6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19790
[Bug c/21391] New: referencing a type via a cast does not emit it for debug
Test program:
struct foo
{
int i;
};
int bar (void)
{
return ((struct foo *)0x1234)-i;
}
Compile with -g; readelf does NOT show a definition of struct foo in the debug
data.
If I compile with -fno-eliminate-unused-debug-types, the definition does
appear, but in the example program, foo isn't unused.
--
Summary: referencing a type via a cast does not emit it for debug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
[Bug debug/21391] [3.4/4.0/4.1 Regression] referencing a type via a cast does not emit it for debug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04 20:36 --- Confirmed, a regression from 3.3.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|c |debug Ever Confirmed||1 Keywords||wrong-debug Known to fail||3.4.0 4.0.0 4.1.0 Known to work||2.95.3 3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-05-04 20:36:21 date|| Summary|referencing a type via a|[3.4/4.0/4.1 Regression] |cast does not emit it for |referencing a type via a |debug |cast does not emit it for ||debug Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-04 20:53 --- Ben -- As I recall the original test case was written in 'nice', not in java. The sources may be of limited usefulness here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug bootstrap/21365] libiberty/regex.c:49:25: error: sys/types.h: No such file or directory
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04 21:18 --- See http://gcc.gnu.org/simtest-howto.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21365
[Bug c/21392] New: Wrong code generated for array of enum with mode attribute
Test code:
typedef enum { false, true } bool __attribute__((mode (byte)));
bool foo[16];
bool test (int i)
{
return foo[i];
}
This works with v3.3.3. With V4.0.0, the generated code is wrong -- it
references the array element as a word (4 bytes) yet indexes it as bytes. In
this particular test case, the generated code does unaligned loads (why is not
clear); in an example in my application where the bool array is on the stack, it
generated a regular word load, killing the program due to an unaligned access.
Presumably related: when I ask gdb what it thinks sizeof(foo[0]) is, I get 4
rather than the expected 1.
--
Summary: Wrong code generated for array of enum with mode
attribute
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf1.6.2
GCC host triplet: i386-unknown-netbsdelf1.6.2
GCC target triplet: mipsel-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
[Bug libfortran/21354] Rank 7 not handled correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04 21:38 --- Subject: Bug 21354 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-04 21:38:23 Modified files: libgfortran: ChangeLog gcc/testsuite : ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 ifunction.m4 in_pack.m4 in_unpack.m4 libgfortran/intrinsics: cshift0.c eoshift0.c eoshift2.c random.c spread_generic.c stat.c libgfortran/generated: all_l4.c all_l8.c any_l4.c any_l8.c count_4_l4.c count_4_l8.c count_8_l4.c count_8_l8.c cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c in_pack_i4.c in_pack_i8.c in_unpack_i4.c in_unpack_i8.c maxloc0_4_i4.c maxloc0_4_i8.c maxloc0_4_r4.c maxloc0_4_r8.c maxloc0_8_i4.c maxloc0_8_i8.c maxloc0_8_r4.c maxloc0_8_r8.c maxloc1_4_i4.c maxloc1_4_i8.c maxloc1_4_r4.c maxloc1_4_r8.c maxloc1_8_i4.c maxloc1_8_i8.c maxloc1_8_r4.c maxloc1_8_r8.c maxval_i4.c maxval_i8.c maxval_r4.c maxval_r8.c minloc0_4_i4.c minloc0_4_i8.c minloc0_4_r4.c minloc0_4_r8.c minloc0_8_i4.c minloc0_8_i8.c minloc0_8_r4.c minloc0_8_r8.c minloc1_4_i4.c minloc1_4_i8.c minloc1_4_r4.c minloc1_4_r8.c minloc1_8_i4.c minloc1_8_i8.c minloc1_8_r4.c minloc1_8_r8.c minval_i4.c minval_i8.c minval_r4.c minval_r8.c product_c4.c product_c8.c product_i4.c product_i8.c product_r4.c product_r8.c sum_c4.c sum_c8.c sum_i4.c sum_i8.c sum_r4.c sum_r8.c Added files: gcc/testsuite/gfortran.dg: in_pack_rank7.f90 Log message: 2005-05-04 Thomas Koenig [EMAIL PROTECTED] PR libfortran/21354 * m4/cshift1.m4: Change dimension of auxiliary arrays from GFC_MAX_DIMENSION - 1 to GFC_MAX_DIMENSION. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/in_pack.m4: Likewise. * m4/in_unpack.m4: Likewise. * intrinsics/cshift0.c: Likewise. * intrinsics/eoshift0.c: Likewise. * intrinsics/eoshift2.c: Likewise. * intrinsics/random.c: Likewise. * intrinsics/spread_generic.c: Likewise. * intrinsics/stat.c: Likewise. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_4_l4.c: Regenerated. * generated/count_4_l8.c: Regenerated. * generated/count_8_l4.c: Regenerated. * generated/count_8_l8.c: Regenerated. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. * generated/in_pack_i4.c: Regenerated. * generated/in_pack_i8.c: Regenerated. * generated/in_unpack_i4.c: Regenerated. * generated/in_unpack_i8.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc0_4_i4.c: Regenerated. *
[Bug libgcj/21140] [4.0 only] Charset.encode and Charset.decode broken
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-04 21:45 --- Note that the patch from the trunk can't be applied to the 4.0 branch, as it would break compatibility for the C++ ABI. My current leaning is to simply disable the caching in 4.0.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21140
[Bug middle-end/20371] Some corner cases of MS bitfields don't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04 21:51 --- Subject: Bug 20371 CVSROOT:/cvs/gcc Module name:gcc Branch: sh-elf-4_1-branch Changes by: [EMAIL PROTECTED] 2005-05-04 21:51:35 Modified files: gcc: ChangeLog tree.h stor-layout.c Log message: PR middle-end/20371: * tree.h (record_layout_info_s): New member prev_packed. * stor-layout.c (update_alignment_for_field): Fix comment about KNOWN_ALIGN. For MS bitfields, if we start a new run, make sure we start it properly aligned. (place_field): At the beginning of a record, pass 0 as KNOWN_ALIGN to update_alignment_for_field, and recompute it afterwards using the alignment of the record. When a packed bitfield precedes an MS bitfield, don't add padding at the end of the packed bitfield on behalf of the base type of the packed bit field. Take possible record alignment BIGGEST_ALIGNMENT into account when calculating actual_align. Only put packed bit fields into rli-prev_field if they end up suitably aligned. Update rli-remaining_in_alignment when we have already started a run of bit fields and we process a packed bit field. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=2.8142.2.8r2=2.8142.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.709r2=1.709.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.228.2.1r2=1.228.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20371
[Bug middle-end/20371] Some corner cases of MS bitfields don't work
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-04 21:54 --- I have found more problems with the ms bitfield code. An amended patch is here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00339.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20371
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-04 23:03 --- I can't trigger this problem anymore with the test case from my original report. I will try to come up with a new test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug c++/21393] New: Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command
Here is what happens, the program ola2.cpp and ola2.ii are available from http://www.idi.ntnu.no/~petrovic/ola2.zip -- furu$ g++ -v -save-temps -o ola2 ola2.cpp -O3 -Wall Reading specs from /store/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs Configured with: /stores/stash/gcc/src-3.4.3-local/gcc-3.4.3/configure --with- local-prefix=/store --prefix=/store --with-included-gettext --with- libiconv=/store/lib Thread model: posix gcc version 3.4.3 /store/libexec/gcc/sparc-sun-solaris2.9/3.4.3/cc1plus -E -quiet -v - iprefix /stores/idislave/.gcc/ver-3.4.3/bin/../lib/gcc/sparc-sun- solaris2.9/3.4.3/ ola2.cpp -mcpu=v7 -Wall -O3 -o ola2.ii ignoring nonexistent directory /stores/idislave/.gcc/ver- 3.4.3/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../include/c++/3.4.3 ignoring nonexistent directory /stores/idislave/.gcc/ver- 3.4.3/bin/../lib/gcc/sparc-sun- solaris2.9/3.4.3/../../../../include/c++/3.4.3/sparc-sun-solaris2.9 ignoring nonexistent directory /stores/idislave/.gcc/ver- 3.4.3/bin/../lib/gcc/sparc-sun- solaris2.9/3.4.3/../../../../include/c++/3.4.3/backward ignoring nonexistent directory /stores/idislave/.gcc/ver- 3.4.3/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.3/include ignoring nonexistent directory /stores/idislave/.gcc/ver- 3.4.3/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../sparc-sun- solaris2.9/include ignoring nonexistent directory /store/lib/gcc/sparc-sun- solaris2.9/3.4.3/../../../../sparc-sun-solaris2.9/include #include ... search starts here: #include ... search starts here: /store/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../include/c++/3.4.3 /store/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../include/c++/3.4.3/sparc- sun-solaris2.9 /store/lib/gcc/sparc-sun- solaris2.9/3.4.3/../../../../include/c++/3.4.3/backward /store/include /store/lib/gcc/sparc-sun-solaris2.9/3.4.3/include /usr/include End of search list. /store/libexec/gcc/sparc-sun-solaris2.9/3.4.3/cc1plus -fpreprocessed ola2.ii - quiet -dumpbase ola2.cpp -mcpu=v7 -auxbase ola2 -O3 -Wall -version -o ola2.s GNU C++ version 3.4.3 (sparc-sun-solaris2.9) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 g++: Internal error: Segmentation Fault (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. -- -- Summary: Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pavel dot petrovic at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21393
[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command
--- Additional Comments From pavel dot petrovic at gmail dot com 2005-05-04 23:25 --- Created an attachment (id=8821) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8821action=view) the refered file that contains ola2.cpp and ola2.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21393
[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 00:00 --- This works for me with the mainline, 3.4.0, and 3.3.3 on i686-pc-linux-gnu, it might be just a stack size limit problem. -- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21393
[Bug middle-end/21392] Wrong code generated for array of enum with mode attribute
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
[Bug middle-end/21392] Wrong code generated for array of enum with mode attribute
-- What|Removed |Added GCC build triplet|i386-unknown-netbsdelf1.6.2 | GCC host triplet|i386-unknown-netbsdelf1.6.2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 00:31 --- (In reply to comment #12) The first attempt is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html patches for pr19664 and 20218 kill gcc bootstrap. gcj fails: /home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/gcj -B/home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/ -B/usr/athlon-pld-linux/bin/ -B/usr/athlon-pld-linux/lib/ -isystem /usr/athlon-pld-linux/include -isystem /usr/athlon-pld-linux/sys-include -ffloat-store -fno-omit-frame-pointer -fclasspath= -fbootclasspath=(long paths) --encoding=UTF-8 -Wno-deprecated -O2 -march=athlon -ggdb -fjni -findirect-dispatch -c (long list of .class) -fPIC -o .libs/gnu-xml.o /tmp/B.27ba32/ccv1kDt2jx:0: internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:191 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 00:37 --- (In reply to comment #13) (In reply to comment #12) The first attempt is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html patches for pr19664 and 20218 kill gcc bootstrap. gcj fails: /home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/gcj -B/home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/ -B/usr/athlon-pld-linux/bin/ -B/usr/athlon-pld-linux/lib/ -isystem /usr/athlon-pld-linux/include -isystem /usr/athlon-pld-linux/sys-include -ffloat-store -fno-omit-frame-pointer -fclasspath= -fbootclasspath=(long paths) --encoding=UTF-8 -Wno-deprecated -O2 -march=athlon -ggdb -fjni -findirect-dispatch -c (long list of .class) -fPIC -o .libs/gnu-xml.o /tmp/B.27ba32/ccv1kDt2jx:0: internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:191 differ crash on amd64: stage1/xgcc -Bstage1/ -B/usr/amd64-pld-linux/bin/ -O2 -ggdb -fprofile-generate -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -c insn-attrtab.c \ -o insn-attrtab.o insn-attrtab.c: In function '_GLOBAL__I_0_insn_current_length': insn-attrtab.c:64398: internal compiler error: Segmentation fault and waiting for powerpc core dump... : -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From pcarlini at suse dot de 2005-05-05 00:47 --- ... maybe, while you are at it, you can check whether the patch for 19664 alone is ok with current mainline?!? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
Double backslashes in fixed header (__FD_ZERO macro)
gcc-3.4.3 contains an incorrect header fix for the __FD_ZERO macro
present in glibc 1.x. The file installed in
prefix/lib/gcc/i686-pc-linux-gnulibc1/3.4.3/include/gnu/types.h
contains the following, with spurious double-backslashes:
/* DO NOT EDIT THIS FILE.
It has been auto-edited by fixincludes from:
/usr/include/gnu/types.h
This had to be done to correct non-standard usages in the
original, manufacturer supplied header file. */
/* This file fixes a bug in the __FD_ZERO macro present in glibc 1.x. */
#ifndef _TYPES_H_WRAPPER
#include features.h
#include_next gnu/types.h
#if defined(__FD_ZERO) !defined(__GLIBC__)
#undef __FD_ZERO
# define __FD_ZERO(fdsetp) \\
do { \\
int __d0, __d1; \\
__asm__ __volatile__(cld ; rep ; stosl \\
: =c (__d0), =D (__d1) \\
: a (0), 0 (__FDSET_LONGS), \\
1 ((__fd_set *) (fdsetp)) :memory); \\
} while (0)
#endif
#define _TYPES_H_WRAPPER
#endif /* _TYPES_H_WRAPPER */
This patch fixes the issue for me:
--- gcc-3.4.3/gcc/fixinc/fixincl.x.orig Sat Aug 14 18:38:10 2004
+++ gcc-3.4.3/gcc/fixinc/fixincl.x Thu May 5 02:28:20 2005
@@ -124,13 +124,13 @@
#include_next gnu/types.h\n\n\
#if defined(__FD_ZERO) !defined(__GLIBC__)\n\
#undef __FD_ZERO\n\
-# define __FD_ZERO(fdsetp) \n\
- do { \n\
-int __d0, __d1; \n\
-__asm__ __volatile__(\cld ; rep ; stosl\ \n\
-\t: \=c\ (__d0), \=D\ (__d1) \n\
-\t: \a\ (0), \0\ (__FDSET_LONGS), \n\
- \1\ ((__fd_set *) (fdsetp)) :\memory\); \n\
+# define __FD_ZERO(fdsetp) \\\n\
+ do { \\\n\
+int __d0, __d1; \\\n\
+__asm__ __volatile__(\cld ; rep ; stosl\ \\\n\
+\t: \=c\ (__d0), \=D\ (__d1) \\\n\
+\t: \a\ (0), \0\ (__FDSET_LONGS), \\\n\
+ \1\ ((__fd_set *) (fdsetp)) :\memory\); \\\n\
} while (0)\n\
#endif\n\n\
#define _TYPES_H_WRAPPER\n\
The following is probably the correct patch (which I can't readily
check as I don't have autogen installed):
--- gcc-3.4.3/gcc/fixinc/inclhack.def.orig Sat Aug 14 18:38:10 2004
+++ gcc-3.4.3/gcc/fixinc/inclhack.def Thu May 5 02:46:20 2005
@@ -82,13 +82,13 @@
#if defined(__FD_ZERO) !defined(__GLIBC__)
#undef __FD_ZERO
- # define __FD_ZERO(fdsetp) \\
- do { \\
- int __d0, __d1; \\
- __asm__ __volatile__(cld ; rep ; stosl \\
- : =c (__d0), =D (__d1) \\
- : a (0), 0 (__FDSET_LONGS), \\
- 1 ((__fd_set *) (fdsetp)) :memory); \\
+ # define __FD_ZERO(fdsetp) \
+ do { \
+ int __d0, __d1; \
+ __asm__ __volatile__(cld ; rep ; stosl \
+ : =c (__d0), =D (__d1) \
+ : a (0), 0 (__FDSET_LONGS), \
+ 1 ((__fd_set *) (fdsetp)) :memory); \
} while (0)
#endif
The same issue might affect the __FD_ZERO macro present in glibc
2.0.x. and other places, but I can't readily test them.
Frank
--
Frank Heckenbach, [EMAIL PROTECTED]
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
[Bug c++/21363] no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated
--- Additional Comments From hingwah at hingwah dot net 2005-05-05 04:58 --- i don't think compiler generated constructor should have the privilege to invoke constructor of parent class which is private. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21363
[Bug c++/21363] no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 05:12 --- (In reply to comment #2) i don't think compiler generated constructor should have the privilege to invoke constructor of parent class which is private. It does not but ICC does the same thing. Try creating an object of the class and you will see GCC errors out which is why I said it is due to the lazyness of the constructor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21363
