Re: No effect of -fshort-enums..is it a bug
* Andreas Schwab [EMAIL PROTECTED] [050921 17:46]: Gaurav Gautam, Noida [EMAIL PROTECTED] writes: Does -fshort-enum guides the size of enumeration type or the size of enumerator constant ? An enumerator constant is not an object, thus it has no size of its own. Since the enumerator constants are of type int, not the enum type, -fshort-enum should not have any effect on their type. I think some warning for this case would be nice. While the value is looks clearly definied, I think almost all cases where this is actually used will be errors. (The same with sizeof(void), which most likely only happens with p=malloc(sizeof(*p)) from macros). Is there already a warning against that (I cannot find any in the info page) or is there any chance to get such a thing implemented? Hochachtungsvoll, Bernhard R. Link
RE: On which platforms is -fvisibility supported?
Original Message From: Jonathan Turkanis Sent: 23 September 2005 01:43 If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. It is actually the _fundamental_ principle under which this particular mailing list operates! cheers, DaveK -- Can't think of a witty .sigline today
Re: Questionable code in fixup_reorder_chain
Hi Jan,
I think fixup_reorder_chain contains questionable code to cope with a
pathological case:
/* The degenerated case of conditional jump jumping to the next
instruction can happen on target having jumps with side
effects.
Create temporarily the duplicated edge representing branch.
It will get unidentified by force_nonfallthru_and_redirect
that would otherwise get confused by fallthru edge not pointing
to the next basic block. */
if (!e_taken)
{
rtx note;
edge e_fake;
bool redirected;
e_fake = unchecked_make_edge (bb, e_fall-dest, 0);
redirected = redirect_jump (BB_END (bb),
block_label (bb), 0);
gcc_assert (redirected);
Note the call to redirect_jump that creates a loop. It is responsible for
the
ICE on the attached Ada testcase with the 3.4.5pre compiler at -O3 because
the
edge and the jump disagree on the target.
Duh. The code is ineed quite ugly side case.
The final patch: http://gcc.gnu.org/ml/gcc-cvs/2003-03/msg01294.html
The original version: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02097.html
Am I right in thinking that the call to redirect_jump must be removed?
I actually believe there was reason for creating the loop (ie
redirecting the edge to anything else than the fallthru egdge
destination) as otherwise we screwed up in
force_nonfallthru_and_redirect and this function (called via
force_nonfallthru) is supposed to redirect the jump back to proper
destination. This is remarkably ugly hack :(
Would be possible to at leat see the RTL and precise ICE this code is
causing?
Honza
Re: Problem with the special live analyzer in global alloc
Hello, I've opened a bugzilla for this: #24034 Bye, -Andreas-
RE: No effect of -fshort-enums..is it a bug
Hi Gaurav,
Please confirm which of the two outputs is correct and why is there
a
difference in the output of two versions of compiler?
Both outputs are correct.
No, the standard is entirely unambiguous:
6.4.4.3 Enumeration constants
Syntax
1 enumeration-constant:
identifier
Semantics
2 An identifier declared as an enumeration constant has type int.
The enumeration constants denoted by the identifiers a, b, and c are
therefore of type int and must have size 4 (on a standard 32-bit
system),
regardless of the size of the enumerated type aa.
Thank you all for your replies. But I have another question to ask
Consider another example
#include stdio.h
int main()
{
enum ff {
p = 0, q = 4294967295, r
};
printf(size = %d %d %d\n, sizeof(enum ff),sizeof(q),
sizeof(r));
printf(value= %d %d %d\n, p,q,r);
}
Its output is with default options on gcc :
size = 8 8 8
value= 0 -1 0
Enumerator are supposed to be int and must have size 4. why are they
being treated as long here and taking 8 bytes? Size of int on my machine
is 4.
Also the compiler doesn't even gives a warning when the tc is compiled.
(Neither output is compliant to the standard, of course, as -fshort-
enums
is a deviation from the standard.)
Nope, the standard is entirely unambiguous:
6.7.2.2 Enumeration specifiers
4 Each enumerated type shall be compatible with an integer type. The
choice
of type is
implementation-defined,97) but shall be capable of representing the
values
of all the
members of the enumeration. The enumerated type is incomplete until
after
the } that
terminates the list of enumerator declarations.
The choice of what integer type to use to store a value of an
enumerated
type is implementation-defined, and if a char is big enough to
represent
all
the values, the implementation is at liberty to use a char.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Questionable code in fixup_reorder_chain
I actually believe there was reason for creating the loop (ie redirecting the edge to anything else than the fallthru egdge destination) as otherwise we screwed up in force_nonfallthru_and_redirect and this function (called via force_nonfallthru) is supposed to redirect the jump back to proper destination. This is remarkably ugly hack :( Note, however, the differences between the version you posted and the version you commited; in particular, the comment about the loop totally disappeared in between, while the code didn't. Would be possible to at leat see the RTL and precise ICE this code is causing? It is reproducible with 3.4.5pre at -O3 on x86: [EMAIL PROTECTED]:~/build/gcc-3_4-branch/native32 gcc/xgcc -Bgcc -S -O3 p.adb -Igcc/ada/rts +===GNAT BUG DETECTED==+ | 3.4.5 20050910 (prerelease) (i586-suse-linux-gnu) GCC error: | | in redirect_branch_edge, at cfgrtl.c:948 | | Error detected at p.adb:70:6 | Do you really want me to send RTL dumps? Thanks for your quick response. -- Eric Botcazou
Re: No effect of -fshort-enums..is it a bug
Hi Gaurav, You could do this... q = 4294967295U Or you could use -std=iso9899:1999 (perhaps with -pedantic) for the compiler to produce an error. Assuming you are using GCC 4.x. Or if you *want* to allow that, you could do this... -std=gnu99 I'm guessing as to which version of GCC you are using, and what command line options you used to compile with, and your platform's architecture. HTH, --Eljay
Re: On which platforms is -fvisibility supported?
Dave Korn wrote: Original Message From: Jonathan Turkanis Sent: 23 September 2005 01:43 If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. It is actually the _fundamental_ principle under which this particular mailing list operates! Jonathan Turkanis wrote: I've asked this question twice at gcc-help, but got no response. I didn't even get a sarcastic response! :-P The end result is that a *user* with a question about the documentation, must grep the souce. That's not a reasonable expectation. cheers, DaveK -- Jonathan Turkanis www.kangaroologic.com
gcc-4.0.2: supporting -fvisibility for solaris ld
The recommended way to build gcc-4.0.2 on Solaris 10 x86 is to use the binutils assembler and the solaris linker: http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 This works, as long as you suppress HAVE_GAS_COMDAT_GROUP ( see http://gcc.gnu.org/ml/gcc/2005-04/msg01332.html ) but the resulting compiler does not support -fvisibility in any useful way, because the solaris linker fails the configure check checking linker for .hidden support. The solaris linker does support .hidden though, so I am looking into adding support for -fvisibility with solaris ld. I have run into a problem, and I have a few questions. If, for purposes of experimentation, I hack up configure so that it sets HAVE_GAS_HIDDEN unconditionally, then make bootstrap succeeds, and I can in fact use the visibility flags, pragmas, and attributes. The resulting binaries show that symbols are correctly marked as LOCL and GLOB in accordance with the visibility selections. So far, so good. The problems start when I specify an -march argument in 32 bit mode. If when compiling I pass -march=pentium, -march=pentium2, etc., I get errors when trying to link more than one object file: ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file thunk32.o type=FUNC; file visibility32.o type=FUNC); If I look at the assembly listings in thunk32.s and visibility32.s I see the same listing that defines __i686.get_pc_thunk.bx in both files: .section.gnu.linkonce.t.__i686.get_pc_thunk.bx,ax,@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx, @function __i686.get_pc_thunk.bx: movl(%esp), %ebx ret In these same object files, there are other .gnu.linkonce sections, but the symbol is always marked .weak: .weak _ZTV3Foo .section.gnu.linkonce.d._ZTV3Foo,aw,@progbits .align 8 .type _ZTV3Foo, @object .size _ZTV3Foo, 16 _ZTV3Foo: .long 0 So unlike all of the other .gnu.linkonce sections, where the contained symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To my mind, the linker is right to complain when linking two objects containing that definition. With COMDAT group support disabled, is it true that part of gcc's implementation of .gnu.linkonce semantics is to make the symbol in the .gnu.linkonce section weak? If so, should symbols like __i686.get_pc_thunk.* also be weak in this instance, instead of global? If not, would someone please explain why not? Would enabling COMDAT group support (the sun linker does support it) remove this problem? If so, can anyone see a way around the fact that the solaris linker considers relocations against discarded symbols a fatal error, and it is nearly inevitable that when using COMDAT groups there will be relocations in the .eh_frame or debug_info sections against .gnu.linkonce sections that will be discarded? Sorry for the length, or if this is all somehow way off base; I'm new to gcc internals... Thanks, Andrew
Re: GCC 4.0.2 RC3
Eric Botcazou wrote: The GCC 4.0.2 RC3 prerelease is spinning now. Regressions on Solaris 2.6, 7, 8 and 9: FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test FAIL: ext/mt_allocator/check_delete.cc execution test FAIL: ext/mt_allocator/check_new.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test FAIL: ext/mt_allocator/tune-1.cc execution test FAIL: ext/mt_allocator/tune-2.cc execution test FAIL: ext/mt_allocator/tune-3.cc execution test FAIL: ext/mt_allocator/tune-4.cc execution test This patch: 2005-09-19 Benjamin Kosnik [EMAIL PROTECTED] 2005-09-19 Jakub Jelinek [EMAIL PROTECTED] to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you investigating these failures? We need to get this resolved ASAP. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
c++ default operators
Hi list I was told that gcc by default, for every class creates operator =, and probably something else. This makes binary file bit larger than it suppose to be. Is it true, and if so, why this is the case ? Can gcc simply not generate that operator? -- Vercetti
Re: [RFC] propagating loop dependences from trees to RTL (for SMS)
On Sep 22, 2005, at 7:39 PM, Kenneth Zadeck wrote: I will pull a patch together tomorrow. There is currently nothing in the code for keeping the region stuff up to date as changes are made to the cfg. For most changes this would not be hard, but for some it is really hard. OK. I've code (about 6 months old) to keep loop info update during jump threading. I couldn't finish that work to keep loop info upto date from very beginning till end at that time. But now, I am seeing some day light, so hopefully I'll get back to it soon. - Devang Daniel Berlin wrote: On Thu, 2005-09-22 at 18:49 -0700, Devang Patel wrote: On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: On Sep 22, 2005 11:25 AM, Zdenek Dvorak [EMAIL PROTECTED] wrote: 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far be the cleanest approach -- admitedly also the one that requires the greatest amount of work. Shouldn't the regions patch allow us to preserve loops quite easily? Any pointer to this regions patch ? Thanks, Ask kenny for a copy. - Devang
[4.0] version '400p', expected version '400*'
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.3-22.sparc.sparc gcc4-4.0.0-0.41.sparc.sparc glibc-2.3.5-0.fc3.1.sparcv9 glibc-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc glibc-devel-2.3.5-0.fc3.1.sparc64 glibc-headers-2.3.5-0.fc3.1.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.12-1.1505sp3.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.3-22.sparc.sparc libgcc-3.4.3-22.sparc.sparc64 libstdc++-3.4.3-22.sparc.sparc libstdc++-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc libstdc++-devel-3.4.3-22.sparc.sparc64 make-3.80-5.sparc nptl-devel-2.3.5-0.fc3.1.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Fri Sep 23 04:57:40 UTC 2005 Currently, using bubblestrap, in gcc cvs 4.0 branch, I get failures like this: Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -fnon-call-exceptions -fprofile-arcs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./profile1.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' FAIL: g++.dg/other/profile1.C (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/g++.dg/other/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -pg -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./profile1.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' PASS: g++.old-deja/g++.law/profile1.C Profiling unsupported (test for bogus messages, line ) FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.law/profile1.C:1: warning: 'profile1.gcda' is version '400p', expected version '400*' Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/../g++ -B/usr/local/src/branch/objdir/gcc/testsuite/../ /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -fprofile-arcs -ftest-coverage -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs -L/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libiberty -lm -m64 -o ./eb83.exe(timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C:1: warning: 'eb83.gcda' is version '400p', expected version '400*' output is: /usr/local/src/branch/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb83.C:1: warning: 'eb83.gcda' is version '400p', expected version '400*' FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) Excess errors:
Re: GCC 4.0.2 RC3
to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you investigating these failures? We need to get this resolved ASAP. I'm on it. -benjamin
Re: GCC 4.0.2 RC3
Benjamin Kosnik wrote: to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you investigating these failures? We need to get this resolved ASAP. I'm on it. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: warning about classpath import
Dave == Dave Korn [EMAIL PROTECTED] writes: Dave What version of CVS are you using, and does it speak the -X Dave option (new in 1.12.x)? Dave http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_16.html#SEC155 By my reading the -X option requires 1.12 to be running on the server as well. So, I'm just going to do an old-style temporarily-breaking import; I'd rather not mess about without changing the installed cvs. Tom
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote: /* Avoid creating invalid subregs, for example when simplifying (x32)255. */ ! if (final_word = GET_MODE_SIZE (inner_mode) ! || (final_word % GET_MODE_SIZE (tmode)) != 0) return NULL_RTX; I think you should just call validate_subreg. Ok with that change. r~
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Sep 23, 2005, at 12:41 PM, Richard Henderson wrote: On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote: /* Avoid creating invalid subregs, for example when simplifying (x32)255. */ ! if (final_word = GET_MODE_SIZE (inner_mode) ! || (final_word % GET_MODE_SIZE (tmode)) != 0) return NULL_RTX; I think you should just call validate_subreg. Ok with that change. Yes. Will do so. - fj r~
Re: gcc-4.0.2: supporting -fvisibility for solaris ld
On Friday, September 23, 2005, at 08:31 AM, Andrew Morrow wrote: If I look at the assembly listings in thunk32.s and visibility32.s I see the same listing that defines __i686.get_pc_thunk.bx in both files: .section .gnu.linkonce.t.__i686.get_pc_thunk.bx,ax,@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx I think this is a port problem. Step the code that does: DECL_ONE_ONLY (decl) = 1; (*targetm.asm_out.unique_section) (decl, 0); named_section (decl, NULL, 0); (*targetm.asm_out.globalize_label) (asm_out_file, name); fputs (\t.hidden\t, asm_out_file); from i386.c:ix86_file_end. For group COMDAT, the label will (should) be external and everybody else should cope with that. For _gnu_linkonce type things, it will (should) be weak. So unlike all of the other .gnu.linkonce sections, where the contained symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To my mind, the linker is right to complain when linking two objects containing that definition. Correct. With COMDAT group support disabled, is it true that part of gcc's implementation of .gnu.linkonce semantics is to make the symbol in the .gnu.linkonce section weak? Yes, gcc should make it weak, one way, or another. If so, should symbols like __i686.get_pc_thunk.* also be weak in this instance, instead of global? Yes. Would enabling COMDAT group support (the sun linker does support it) remove this problem? It should, unless the SUN linker is broken and assuming no other issues in the compiler that prevent it from working.
Question about the use of builtins in altivec.h
Hello all, I am an active AltiVec PPC assembly programmer, but until recently have not been using gcc's AltiVec extensions. However, lately, with a project I am contributing to, called macstl (www.pixelglow.com/macstl/), I've become involved in using this stuff. So there is my question: why would one define the vec_XXX routines in terms of __builtin_altivec_XXX compiler primitives as opposed to using inline asm statements? Is there any good reason for doing that with the already existing good support for inline assembly? Now, it is important to note: I am *not* using the builtins directly; I am invoking the vec_XXX functions that are defined in altivec.h and specified in the AltiVec PIM. I am asking this, because we're having some problems with those builtins inlining instructions properly when a certain level of logic complexity (in loops) arises. Even worse, gcc 4.0 (both 4.0.0 and 4.0.1) generates bad code (whereas gcc 3.4 is OK). 3.4 simply resorts to a series of calls to compiler generated routines (with mangled names such as _Z7vec_addU8_vectorfs probably corresponding to the vec_add's builtin) instead of inlining actual instructions. Again that happens when a certain level of code mass is reached. gcc 4.0 tries to do the same but, apparently, something goes wrong. I didn't inspect the produced assembly code in depth. Currently, I can only give examples in terms of the macstl expressions and compiler generated assembly output, but if you request, I can try to write a more direct loop that uses the vec_* code. So does anyone of you, compiler writers, know why the builtins are needed? Also, does anyone care that this stuff doesn't really work? Regards, Ilya
Re: Question about the use of builtins in altivec.h
On Sep 23, 2005, at 5:30 PM, Ilya Lipovsky wrote: Hello all, I am asking this, because we're having some problems with those builtins inlining instructions properly when a certain level of logic complexity (in loops) arises. Even worse, gcc 4.0 (both 4.0.0 and 4.0.1) generates bad code (whereas gcc 3.4 is OK). 3.4 simply resorts to a series of calls to compiler generated routines (with mangled names such as _Z7vec_addU8_vectorfs probably corresponding to the vec_add's builtin) instead of inlining actual instructions. Again that happens when a certain level of code mass is reached. gcc 4.0 tries to do the same but, apparently, something goes wrong. I didn't inspect the produced assembly code in depth. Currently, I can only give examples in terms of the macstl expressions and compiler generated assembly output, but if you request, I can try to write a more direct loop that uses the vec_* code. As always read http://gcc.gnu.org/bugs.html and file a bug. The inlining problem have been fixed for 4.1.0, by the stuff mentioned below. Also smaller the testcase the better So does anyone of you, compiler writers, know why the builtins are needed? The builtins are required so the compiler can schedule the code correctly. In 4.1.0, the altivec.h header have been rewritten so that we don't use inline functions but some builtins directly. Also, does anyone care that this stuff doesn't really work? Well there was a rewrite for 4.1.0 for the altivec.h header which should improve this. And also in both 4.0.0 and 4.1.0, there is autovectorization which should expose more bugs. Also sometime during either 3.4.0, 4.0.0, or 4.1.0, an altivec testsuite was addded. Thanks, Andrew Pinski
Re: c++ default operators
On Fri, Sep 23, 2005 at 07:09:21PM +0200, Tommy Vercetti wrote: I was told that gcc by default, for every class creates operator =, and probably something else. This makes binary file bit larger than it suppose to be. Is it true, and if so, why this is the case ? Can gcc simply not generate that operator? In the C++ language, we have the concept of the default assignment operator and the default copy constructor, which are created if needed by the compiler. But gcc won't create these if they aren't used. Another extra function people sometimes complain about is the two copies of the constructor: the in-charge version is for constructing an instance of the class, and the not-in-charge version is for initializing the base portion of a derived class. Getting rid of the not-in-charge version, for cases where it isn't needed, would require something like Java's final keyword.
Re: c++ default operators
Joe Buck wrote: Another extra function people sometimes complain about is the two copies of the constructor: the in-charge version is for constructing an instance of the class, and the not-in-charge version is for initializing the base portion of a derived class. Getting rid of the not-in-charge version, for cases where it isn't needed, would require something like Java's final keyword. Can't you get rid of the not-in-charge version by using -ffunction-sections and then linking with -Wl,--gc-sections (at least for an ELF/GNU binutils target)? David Daney
[Bug c++/24029] New: Invalid handling of multiple includes of precompiled header
The issue is the same as in #13675, but it still exists in GCC4. The problem is: #include precompiled.h #include precompiled.h gives: $ g++ test.cpp test.cpp:2:21: calling fdopen: Bad file descriptor -- Summary: Invalid handling of multiple includes of precompiled header Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a dot darovskikh at compassplus dot ru CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: everywhere http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24029
[Bug bootstrap/23776] configure: error: no acceptable cc found in $PATH
--- Additional Comments From filip693 at wp dot pl 2005-09-23 08:53 --- Subject: Odp: configure: error: no acceptable cc found in $PATH Dnia 8-09-2005 o godz. 13:06 pinskia at gcc dot gnu dot org napisa³(a): --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08 11:06 --- Do you have a compiler installed? You need a compiler installed to build/install GCC. -- What|Removed |Added Status|UNCONFIRMED |WAITING Component|debug |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23776 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. So where can I find a compiler and how to install it ? Korzystny kredyt mieszkaniowy? Tak, to tutaj! Najni¿sze oprocentowanie - ju¿ od 1,60% w CHF! Kliknij i sprawd¼: http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fop9.htmlsid=504 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23776
[Bug libstdc++/24025] libstdc++ crashes when out of memory exception thrown
--- Additional Comments From pcarlini at suse dot de 2005-09-23 09:45 --- Adding Rth in CC as the author of the fix of libstdc++/10606, which added the call of __cxa_get_globals from __cxa_allocate_exception -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-23 09:58 --- I've rewritten execute_cse_reciprocals, I think the only useful solution is to implement the optimal scheme for inserting reciprocals, and fix this bug in the process. My algorithm builds a mock dominator tree including only the basic blocks with the divides and their common dominators, and then inserts divides whenever it is necessary to satisfy these conditions: 1) if -ftrapping-math, the basic block must have one divide 2) in addition, at least two divides must either be in the basic block, or postdominate it. I still have to run some coverage tests, then I'll post the patch. If anybody wants to help, I'd be thankful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug target/23674] ICE on valid code
--- Additional Comments From wouter at grep dot be 2005-09-23 10:14 --- *** This bug has been marked as a duplicate of 23078 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23674
[Bug target/23078] [4.0 regression] m68k ICE
--- Additional Comments From wouter at grep dot be 2005-09-23 10:14 --- *** Bug 23674 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
[Bug ada/24030] New: libada not rebuilt when libbackend is
Doing a simple build (no bootstrap), on x86-linux: $ ../gcc/configure --prefix=/home/guerby/tmp/install1 --disable-multilib --enable-languages=c,ada --disable-nls --enable-threads=posix $ make m1.log $ touch ../gcc/gcc/gimplify.c $ make m2.log $ In m2.log I see that libbackend is rebuilt, as are gnat1 and gnat tools but libada is not rebuilt so I think there's a missing dependancy somewhere. Am I alone in seeing this? -- Summary: libada not rebuilt when libbackend is Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org,neroden at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug ada/24030] libada not rebuilt when libbackend is
-- What|Removed |Added CC||charlet at adacore dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 12:06 --- Subject: Bug 23837 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 12:05:58 Modified files: gcc: ChangeLog optabs.c Log message: PR rtl-optimization/23837 * optabs.c (no_conflict_move_test): Don't set must_stay for a clobber / clobber match between dest and p-first. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10007r2=2.10008 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gccr1=1.291r2=1.292 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 12:15 --- Subject: Bug 23991 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 12:15:43 Modified files: gcc: ChangeLog Log message: Add PR number in this entry: PR middle-end/23991 * final.c (insn_default_length, insn_min_length): In !HAVE_ATTR_length case, define as macros. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10009r2=2.10010 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug c++/24032] New: [sh4] ICE building libstc++ bitmap_allocator.cc
Building a tool chain for sh4 results in the following ICE: /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/./gcc/xgcc -v -save-temps-shared-libgcc -B/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/./gcc -nostdinc++ -L/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/src -L/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/src/.libs -B/opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/bin/ -B/opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/lib/ -isystem /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/include -isystem /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/sys-include -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include/sh4-linux -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/gcc-4.1-20050917/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/gcc-4.1-20050917/libstdc++-v3/src/bitmap_allocator.cc -fPIC -DPIC -o .libs/bitmap_allocator.o Reading specs from /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/./gcc/specs Target: sh4-linux Configured with: /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/gcc-4.1-20050917/configure --target=sh4-linux --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux --with-multilib-list=m4,m4-nofpu --with-headers=/opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/include --with-local-prefix=/opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.1.0 20050917 (experimental) /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/./gcc/cc1plus -E -quiet -nostdinc++ -v -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include/sh4-linux -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include -I/home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/gcc-4.1-20050917/libstdc++-v3/libsupc++ -iprefix /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/gcc/../lib/gcc/sh4-linux/4.1.0/ -isystem /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/./gcc/include -D_GNU_SOURCE -D_GNU_SOURCE -DPIC -isystem /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/include -isystem /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/sh4-linux/sys-include /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/gcc-4.1-20050917/libstdc++-v3/src/bitmap_allocator.cc -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -fworking-directory -O2 -fpch-preprocess -o bitmap_allocator.ii ignoring nonexistent directory /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/gcc/../lib/gcc/sh4-linux/4.1.0/include ignoring nonexistent directory /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/gcc/../lib/gcc/sh4-linux/4.1.0/../../../../sh4-linux/sys-include ignoring nonexistent directory /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/gcc/../lib/gcc/sh4-linux/4.1.0/../../../../sh4-linux/include ignoring nonexistent directory /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/lib/gcc/sh4-linux/4.1.0/include ignoring duplicate directory /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/lib/../sh4-linux/sys-include ignoring duplicate directory /opt/crosstool-sh4/gcc-4.1-20050917-glibc-2.3.5/sh4-linux/lib/../sh4-linux/include #include ... search starts here: #include ... search starts here: /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include/sh4-linux /home/alex/crosstool/crosstool-0.38/build/sh4-linux/gcc-4.1-20050917-glibc-2.3.5/build-gcc/sh4-linux/libstdc++-v3/include
[Bug c++/24032] [sh4] ICE building libstc++ bitmap_allocator.cc
--- Additional Comments From sieb at sscd dot de 2005-09-23 12:17 --- Created an attachment (id=9795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9795action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24032
[Bug middle-end/17667] Const/pure function detection during tree-based profiling
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-23 12:21 --- Fixed by Kenny's patch -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17667
[Bug tree-optimization/24028] CCP is broken
--- Additional Comments From dnovillo at redhat dot com 2005-09-23 12:30 --- Subject: Re: CCP is broken On September 23, 2005 01:29, kazu at gcc dot gnu dot org wrote: --- Additional Comments From kazu at gcc dot gnu dot org 2005-09-23 05:29 --- The reason why CCP thinks that the result of the PHI node is varying is because ccp_initialize thinks that a PHI node is varying if at least one of PHI argument is varying. This is very related to 23588. The heuristics to speed up propagation are crippling the propagator. likely_value and ccp_initialize are the main functions to start fixing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24028
[Bug middle-end/24020] [4.0 regression] Excessive (x20) recusive inlining for 4.0 with -O3 and poor stack usage even without inlining
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-23 12:37 --- There is no recursive inlining happening at least on 4.1 because of overall unit growth limit is met, so we do remarkably worse compared to 3.4 anyway. Enabling recursive inlining makes it very active. This is side effect of last growth model changes and I need to trottle this somehow. Honza -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Summary|[4.0 regression] Excessive |[4.0 regression] Excessive |(x20) recusive inlining for |(x20) recusive inlining for |4.0 with -O3|4.0 with -O3 and poor stack ||usage even without inlining http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24020
[Bug c++/24029] Invalid handling of multiple includes of precompiled header
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:44 --- This is a dup of bug 13675. We don't need a seperate bug to track this for 3.4.0 and 4.0.0. *** This bug has been marked as a duplicate of 13675 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24029
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:45 --- *** Bug 24029 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||a dot darovskikh at ||compassplus dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug target/23078] [4.0 regression] m68k ICE
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
[Bug c++/24032] [sh4] ICE building libstc++ bitmap_allocator.cc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:47 --- *** This bug has been marked as a duplicate of 22553 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24032
[Bug target/22553] [4.1 regression] ICE building libstdc++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:47 --- *** Bug 24032 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sieb at sscd dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug middle-end/17667] Const/pure function detection during tree-based profiling
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17667
[Bug middle-end/24020] [4.0 regression] Excessive (x20) recusive inlining for 4.0 with -O3 and poor stack usage even without inlining
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-23 12:49 --- The difference in stack usage is caused by ivopts. -fno-ivopts reduces 4.1 stack usage to 12 bytes and 200 bytes with --param inline-unit-growth=100 Especially in the second case ivops should probably trottle down after some loop nest as it makes no sense to increase number of induction variables for each of loop of nest8. I will look into saner recursive inlining limits too. -- What|Removed |Added AssignedTo|hubicka at gcc dot gnu dot |rakdver at atrey dot karlin |org |dot mff dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24020
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:50 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:55 --- Actually none of the target libraries are rebuilt after the compiler is rebuilt. -- What|Removed |Added Severity|normal |minor Component|ada |bootstrap Summary|libada not rebuilt when |target libraries are not |libbackend is |rebuilt after gcc is rebuilt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug target/24027] A gcc primitive, under special circumstances, can crash the AVR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:56 --- Is there some source someone can look at? -- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24027
[Bug middle-end/23785] 197.parser performance drop
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-23 12:56 --- Both paches are affecting inlining decisions and it looks like parser somehow got unlucky on PPC (they didn't cause similar regression on parser for AMD64). It would be very useful to know what function inlininig changed and caused the difference. The inlining decisions can be dumped with -fdump-ipa-all Honza -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug tree-optimization/24026] cleanup_control_expr_graph uses fold to fold COND_EXPR_COND
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 12:59 --- The main issue is that the inliner does fold as it is replacing the use. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||compile-time-hog Last reconfirmed|-00-00 00:00:00 |2005-09-23 12:59:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24026
[Bug c++/23967] misleading error message for ambiguous namespace reference
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 13:22 --- *** This bug has been marked as a duplicate of 12272 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23967
[Bug c++/12272] wrong error message using declaration shadows namespace
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 13:22 --- *** Bug 23967 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jens dot maurer at gmx dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12272
[Bug c++/24011] ambiguous overload reported for no obvious reason
--- Additional Comments From andre_orwell at yahoo dot com dot au 2005-09-23 13:34 --- Subject: Re: ambiguous overload reported for no obvious reason Thanks - obvious when its pointed out. Sorry for the bother. On Friday 23 September 2005 01:17, pinskia at gcc dot gnu dot org wrote: The following code does what you wanted to do: ... Notice how I wrote the Implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24011
[Bug rtl-optimization/24034] Regrename: Inconsistency Failure
-- What|Removed |Added OtherBugsDependingO||15023 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24034
[Bug rtl-optimization/24034] Regrename: Inconsistency Failure
-- What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24034
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Additional Comments From charlet at adacore dot com 2005-09-23 14:13 --- Subject: Re: libada not rebuilt when libbackend is What|Removed |Added CC||charlet at adacore dot com Thanks for the cc:, although I do monitor all Ada bugs, so do not worry, I saw your report ;-) Unfortunately, I am not a libada (actually GCC configure, script, makefile) expert so I am not the best person to ask. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-23 14:26 --- Removing myself from cc: to avoid receiving each message on this PR twice... -- What|Removed |Added CC|charlet at adacore dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug middle-end/24036] New: [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
ICE when using -mfloat-gprs=double with -mspe=no. Found in the e500 branch,
reproducible in mainline.
Test case:
typedef double _Complex _Dcomplex;
double (cabs)(_Dcomplex x) { }
[EMAIL PROTECTED] rmansfield]$
/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/bin/powerpc-linux-gnuspe-gcc
-mfloat-gprs=double -mcpu=8548 ~/cabs.i -c -mspe=no -v
Using built-in specs.
Target: powerpc-linux-gnuspe
Configured with:
/home/rmansfield/crosstool-0.28-rc37/build/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/gcc-head/configure
--target=powerpc-linux-gnuspe --host=i686-host_pc-linux-gnu
--prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5
--with-local-prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/powerpc-linux-gnuspe
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 4.1.0 20050917 (experimental)
/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/libexec/gcc/powerpc-linux-gnuspe/4.1.0/cc1
-fpreprocessed /home/rmansfield/cabs.i -quiet -dumpbase cabs.i
-mfloat-gprs=double -mcpu=8548 -mspe=no -auxbase cabs -version -o
/tmp/ccNYZQDL.s
GNU C version 4.1.0 20050917 (experimental) (powerpc-linux-gnuspe)
compiled by GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 947d94ba0d127e0ee2614bdf9bacf926
/home/rmansfield/cabs.i: In function 'cabs':
/home/rmansfield/cabs.i:3: internal compiler error: in
subreg_offset_representable_p, at rtlanal.c:3143
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
If this is reproducible in mainline, could you submit this bug in bugzilla
and
assign it to me?
Thanks
Aldy
--
Summary: [e500] ICE in subreg_offset_representable_p, at
rtlanal.c:3143
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: aldyh at redhat dot com
ReportedBy: rmansfield at qnx dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-host_pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23
16:47 ---
Hmm, my simple example shows that this is a regression also in 3.4.0 but that
looks like a different
bug than the orginal one.
Anyways here is the reduced testcase for the reported bug, I will file the
other one in a different bug:
# 1 t.cc
# 1 built-in
# 1 command line
# 1 t.cc
# 1 t.h 1
namespace t
{
using ::t1;
}
# 2 t.cc 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/24037] New: [3.4/4.0/4.1 regression] C++ front-end does not print #include stack for parsering errors
Take the following preprocessed souece: # 1 t.c # 1 built-in # 1 command line # 1 t.c # 1 t.h 1 1 # 2 t.c 2 cut -- with this in 3.3.3, we got: In file included from t.c:1: t.h:1: error: parse error before numeric constant But in 3.4.0 and above: t.h:1: error: expected unqualified-id before numeric constant Which does not help at all. -- Summary: [3.4/4.0/4.1 regression] C++ front-end does not print #include stack for parsering errors Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
[Bug c++/24037] [3.4/4.0/4.1 regression] C++ front-end does not print #include stack for parsering errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 16:51 --- This was caused by the new parser. The C front-end is not effected. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 16:51 --- Filed comment #2 as PR 24037. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 16:54 --- Caused between 20040920 and 20040921 which means this was caused by: 2004-09-20 Matt Austern [EMAIL PROTECTED] Zack Weinberg [EMAIL PROTECTED] Note there was a time in 3.4.x were he had the same issue too but I have not tracked down the date either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug middle-end/24038] New: [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
ICE when using -mfloat-gprs=double with -mspe=no. Found in the e500 branch,
reproducible in mainline.
Test case:
typedef double _Complex _Dcomplex;
double (cabs)(_Dcomplex x) { }
[EMAIL PROTECTED] rmansfield]$
/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/bin/powerpc-linux-gnuspe-gcc
-mfloat-gprs=double -mcpu=8548 ~/cabs.i -c -mspe=no -v
Using built-in specs.
Target: powerpc-linux-gnuspe
Configured with:
/home/rmansfield/crosstool-0.28-rc37/build/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/gcc-head/configure
--target=powerpc-linux-gnuspe --host=i686-host_pc-linux-gnu
--prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5
--with-local-prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/powerpc-linux-gnuspe
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 4.1.0 20050917 (experimental)
/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/libexec/gcc/powerpc-linux-gnuspe/4.1.0/cc1
-fpreprocessed /home/rmansfield/cabs.i -quiet -dumpbase cabs.i
-mfloat-gprs=double -mcpu=8548 -mspe=no -auxbase cabs -version -o
/tmp/ccNYZQDL.s
GNU C version 4.1.0 20050917 (experimental) (powerpc-linux-gnuspe)
compiled by GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 947d94ba0d127e0ee2614bdf9bacf926
/home/rmansfield/cabs.i: In function 'cabs':
/home/rmansfield/cabs.i:3: internal compiler error: in
subreg_offset_representable_p, at rtlanal.c:3143
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
If this is reproducible in mainline, could you submit this bug in bugzilla
and
assign it to me?
Thanks
Aldy
--
Summary: [e500] ICE in subreg_offset_representable_p, at
rtlanal.c:3143
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: aldyh at redhat dot com
ReportedBy: rmansfield at qnx dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-host_pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24038
[Bug middle-end/24038] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 16:59 --- *** This bug has been marked as a duplicate of 24036 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24038
[Bug middle-end/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 16:59 --- *** Bug 24038 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
-- What|Removed |Added Component|middle-end |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
[Bug fortran/16861] [4.0 only] segfault with doubly used module
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 17:16 --- Subject: Bug 16861 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 17:16:07 Modified files: gcc/fortran: module.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: nested_modules_3.f90 Log message: 2005-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/16861 * module.c (mio_component_ref): Return if the symbol is NULL and wait for another iteration during module reads. (mio_symtree_ref): Suppress the writing of contained symbols, when a symbol is available in the main namespace. (read_module): Restrict scope of special treatment of contained symbols to variables only and suppress redundant call to find_true_name. 2005-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/16861 * gfortran.dg/nested_modules_3.f90: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gccr1=1.39r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.567r2=1.568 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6100r2=1.6101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_3.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From dj at redhat dot com 2005-09-23 17:22 --- Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer I recall that the opposite case is problematic; initializing a large int from a smaller one, because gcc always zero pads at the end. Perhaps a lt/gt comparison would be more appropriate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Additional Comments From laurent at guerby dot net 2005-09-23 17:33
---
The 17 x86 only regressions were introduced by this patch, Jan asked me to look
for generated libcalls, more info soon.
2005-09-18 Jan Hubicka [EMAIL PROTECTED]
* calls.c (flags_from_decl_or_type): Do not set ECF_LIBCALL_BLOCK.
Index: calls.c
===
RCS file: /opt/gcc/rsync/gcc-cvs/gcc/gcc/calls.c,v
retrieving revision 1.400
retrieving revision 1.401
diff -u -r1.400 -r1.401
--- calls.c 31 Aug 2005 03:33:23 - 1.400
+++ calls.c 18 Sep 2005 17:14:24 - 1.401
@@ -582,7 +582,7 @@
/* The function exp may have the `pure' attribute. */
if (DECL_IS_PURE (exp))
- flags |= ECF_PURE | ECF_LIBCALL_BLOCK;
+ flags |= ECF_PURE;
if (DECL_IS_NOVOPS (exp))
flags |= ECF_NOVOPS;
@@ -591,7 +591,7 @@
flags |= ECF_NOTHROW;
if (TREE_READONLY (exp) ! TREE_THIS_VOLATILE (exp))
- flags |= ECF_LIBCALL_BLOCK | ECF_CONST;
+ flags |= ECF_CONST;
flags = special_function_p (exp, flags);
}
@@ -606,7 +606,7 @@
if (TREE_CODE (type) == FUNCTION_TYPE TYPE_RETURNS_STACK_DEPRESSED (type))
{
flags |= ECF_SP_DEPRESSED;
- flags = ~(ECF_PURE | ECF_CONST | ECF_LIBCALL_BLOCK);
+ flags = ~(ECF_PURE | ECF_CONST);
}
return flags;
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug preprocessor/24039] New: cpp segfaults when a non-existent include is encountered
Target: sparc64-sun-solaris2.9 Configured with: ../gcc-4.1-20050917/configure --enable-threads --enable-multilib --with-cpu=v9 --with-tune=ultrasparc sparc64-sun-solaris2.9 --enable-languages=c,c++ Thread model: posix gcc version 4.1.0 20050917 (experimental) sparc% /usr/local/bin/cpp test.c # 1 test.c # 0 built-in # 1 command line # 1 test.c test.c:1:22: built-in:0: internal compiler error: Segmentation Fault sparc% cat test.c #include segfault.h sparc% more test.i # 1 test.c # 0 built-in # 1 command line # 1 test.c -- Summary: cpp segfaults when a non-existent include is encountered Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: heas at shrubbery dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64-sun-solaris2.9 GCC host triplet: sparc64-sun-solaris2.9 GCC target triplet: sparc64-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug preprocessor/24040] New: ICE -Wp,-traditional-cpp in cpp_spell_token at ..gcc/cpplex.c
ICE when -Wp,-traditional-cpp is set. No problem with -traditional-cpp. I don't
know if -Wp,-traditional-cpp is even supported usage because the manual says -E
should be used with -traditional-cpp.
Testcase:
[EMAIL PROTECTED]:~$ cat small.c
#define foo(a, b) c=a; d=b;
int main ()
{
char *c, *d;
foo (p, q);
}
[EMAIL PROTECTED]:~$ /home/ryan/bin/gcc -v -Wp,-traditional-cpp small.c
Reading specs from /home/ryan/lib/gcc/i686-pc-linux-gnu/3.4.5/specs
Configured with: ../configure --prefix=/home/ryan --enable-languages=c
Thread model: posix
gcc version 3.4.5 20050923 (prerelease)
/home/ryan/libexec/gcc/i686-pc-linux-gnu/3.4.5/cc1 -quiet -v -traditional-cpp
small.c -quiet -dumpbase small.c -mtune=pentiumpro -auxbase small -version -o
/tmp/ccCcvE05.s
ignoring nonexistent directory
/home/ryan/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/home/ryan/include
/home/ryan/lib/gcc/i686-pc-linux-gnu/3.4.5/include
/usr/include
End of search list.
GNU C version 3.4.5 20050923 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050919 (experimental).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64679
small.c: In function `main':
small.c:5: 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.
--
Summary: ICE -Wp,-traditional-cpp in cpp_spell_token at
..gcc/cpplex.c
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx 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=24040
[Bug fortran/23884] failure in gcc
--- Additional Comments From segalemb at usp dot br 2005-09-23 19:12 --- Subject: Re: failure in gcc I and another person searched carrefully the source code and there is no repeated data commands. Sergio Citando pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 19:29 --- Reduced testcase: module param double precision mutdefc(8,5,7) data mutdefc(1,1,7) /0.d0/ * mutdefc(1,1,7) /0.d0/ end module param But this is really a dup of bug 17737 *** This bug has been marked as a duplicate of 17737 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23884 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23884
[Bug java/9861] method name mangling ignores return type
--- Additional Comments From tj at laurenzo dot org 2005-09-23 19:20 --- I have submitted a patch to fix this bug to the gcc-patches mailing list. The URL of the message is: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01496.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
[Bug preprocessor/24040] [3.4 Regression] ICE -Wp,-traditional-cpp in cpp_spell_token at ..gcc/cpplex.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 19:27 --- Confirmed, only a 3.4 regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Known to fail||3.4.0 Known to work||4.0.0 4.1.0 4.0.1 Last reconfirmed|-00-00 00:00:00 |2005-09-23 19:27:07 date|| Summary|ICE -Wp,-traditional-cpp in |[3.4 Regression] ICE -Wp,- |cpp_spell_token at |traditional-cpp in |..gcc/cpplex.c |cpp_spell_token at ||..gcc/cpplex.c Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24040
[Bug fortran/23884] failure in gcc
--- Additional Comments From segalemb at usp dot br 2005-09-23 19:27 --- Subject: Re: failure in gcc I and another person searched carrefully the source code and there is no repeated data commands. Sergio Citando pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 19:29 --- Reduced testcase: module param double precision mutdefc(8,5,7) data mutdefc(1,1,7) /0.d0/ * mutdefc(1,1,7) /0.d0/ end module param But this is really a dup of bug 17737 *** This bug has been marked as a duplicate of 17737 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23884 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23884
[Bug preprocessor/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 19:28 --- This works for me on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug preprocessor/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 19:45 --- Can you add -v and give the output? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Additional Comments From laurent at guerby dot net 2005-09-23 19:46 --- Beginning of the -fdump-tree-all diff before and after patch. -- before/s-arit64.adb.00.expand 2005-09-23 20:01:11.0 +0200 +++ after/s-arit64.adb.00.expand2005-09-23 19:41:23.0 +0200 @@ -2795,143 +2795,119 @@ (call_insn/u 18 17 19 (set (reg:SI 0 ax) (call (mem:QI (symbol_ref:SI (system__arith_64__hi) [flags 0x3] function_decl 0x40196d80 system__arith_64__hi) [0 S1 A8]) (const_int 8 [0x8]))) -1 (nil) -(nil) +(expr_list:REG_EH_REGION (const_int 0 [0x0]) +(nil)) (expr_list:REG_DEP_TRUE (use (mem/i:DI (reg/f:SI 56 virtual-outgoing-args) [0 S8 A32])) (nil))) -(insn 19 18 20 (set (reg:SI 73) +(insn 19 18 0 (set (reg/v:SI 66 [ xhi ]) (reg:SI 0 ax)) -1 (nil) -(expr_list:REG_EQUAL (expr_list:REG_DEP_TRUE (symbol_ref:SI (system__arith_64__hi) [flags 0x3] function_decl 0x40196d80 system__arith_64__hi) -(expr_list:REG_DEP_TRUE (reg/v:DI 67 [ xu ]) -(nil))) -(nil))) - -(insn 20 19 0 (set (reg/v:SI 66 [ xhi ]) -(reg:SI 73)) -1 (nil) (nil)) ;; xlo = system__arith_64__lo (xu) -(insn 22 20 23 (set (mem:DI (reg/f:SI 56 virtual-outgoing-args) [0 S8 A32]) +(insn 21 19 22 (set (mem:DI (reg/f:SI 56 virtual-outgoing-args) [0 S8 A32]) (reg/v:DI 67 [ xu ])) -1 (nil) (nil)) -(call_insn/u 23 22 24 (set (reg:SI 0 ax) +(call_insn/u 22 21 23 (set (reg:SI 0 ax) (call (mem:QI (symbol_ref:SI (system__arith_64__lo) [flags 0x3] function_decl 0x40196d00 system__arith_64__lo) [0 S1 A8]) (const_int 8 [0x8]))) -1 (nil) -(nil) +(expr_list:REG_EH_REGION (const_int 0 [0x0]) +(nil)) (expr_list:REG_DEP_TRUE (use (mem/i:DI (reg/f:SI 56 virtual-outgoing-args) [0 S8 A32])) (nil))) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug preprocessor/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From heas at shrubbery dot net 2005-09-23 19:57 --- Subject: Re: cpp segfaults when a non-existent include is encountered Fri, Sep 23, 2005 at 07:45:59PM -, pinskia at gcc dot gnu dot org: Can you add -v and give the output? Sure. sparc% gcc-bin -v -save-temps -c test.c Using built-in specs. Target: sparc64-sun-solaris2.9 Configured with: ../gcc-4.1-20050917/configure --enable-threads --enable-multilib --with-cpu=v9 --with-tune=ultrasparc sparc64-sun-solaris2.9 --enable-languages=c,c++ Thread model: posix gcc version 4.1.0 20050917 (experimental) /usr/local/libexec/gcc/sparc64-sun-solaris2.9/4.1.0/cc1 -E -quiet -v -D__arch64__ -D__sparcv9 test.c -mcpu=v9 -mtune=ultrasparc -fpch-preprocess -o test.i ignoring nonexistent directory NONE/include ignoring nonexistent directory /usr/local/lib/gcc/sparc64-sun-solaris2.9/4.1.0/../../../../sparc64-sun-solaris2.9/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/lib/gcc/sparc64-sun-solaris2.9/4.1.0/include /usr/include End of search list. test.c:1:22: built-in:0: 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. How do I make it dump a core instead of catching the signal? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug preprocessor/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 20:02 --- -dH but there is a better way to get a backtrace. use gdb --args /usr/local/libexec/gcc/sparc64-sun-solaris2.9/4.1.0/cc1 -E -quiet -v -D__arch64__ -D__sparcv9 test.c -mcpu=v9 -mtune=ultrasparc -fpch-preprocess -o test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug preprocessor/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From heas at shrubbery dot net 2005-09-23 21:23 --- Subject: Re: cpp segfaults when a non-existent include is encountered Fri, Sep 23, 2005 at 08:02:17PM -, pinskia at gcc dot gnu dot org: -dH but there is a better way to get a backtrace. use gdb --args /usr/local/libexec/gcc/sparc64-sun-solaris2.9/4.1.0/cc1 -E -quiet -v -D__arch64__ -D__sparcv9 test.c -mcpu=v9 -mtune=ultrasparc -fpch-preprocess -o test.i nice. here is the trace: #0 0x7f23d28c in strlen () from /usr/lib/64/libc.so.1 #1 0x7f29c318 in fputs () from /usr/lib/64/libc.so.1 #2 0x0001005ed5f4 in _cpp_begin_message (pfile=Variable pfile is not available. ) at ../../gcc-4.1-20050917/libcpp/errors.c:120 #3 0x0001005ed8c8 in cpp_error (pfile=0x1, level=3, msgid=0x1006b71e0 %s: %s) at ../../gcc-4.1-20050917/libcpp/errors.c:155 #4 0x0001005f2184 in _cpp_find_file (pfile=0x100903300, fname=0x100907010 segfault.h, start_dir=0x1008d1890, fake=28 '\034') at ../../gcc-4.1-20050917/libcpp/files.c:436 #5 0x0001005f2e60 in _cpp_stack_include (pfile=0x100903300, fname=0x100907010 segfault.h, angle_brackets=1, type=IT_INCLUDE) at ../../gcc-4.1-20050917/libcpp/files.c:820 #6 0x0001005eaf70 in do_include_common (pfile=0x100903300, type=IT_INCLUDE) at ../../gcc-4.1-20050917/libcpp/directives.c:695 I stepped through it, and it appears to be failing with a gettext call. not the exact location: (gdb) whe #0 libintl_dcigettext (domainname=0x1006b71a0 cpplib, msgid1=0x1006b71d0 error: , msgid2=0x0, plural=0, n=0, category=5) at ../../gcc-4.1-20050917/intl/dcigettext.c:579 #1 0x0001005ff234 in libintl_dgettext (domainname=0x1006b71a0 cpplib, msgid=0x1006b71d0 error: ) at ../../gcc-4.1-20050917/intl/dgettext.c:53 #2 0x0001005ed5dc in _cpp_begin_message (pfile=Variable pfile is not available. ) at ../../gcc-4.1-20050917/libcpp/errors.c:120 ... (gdb) libintl_dgettext (domainname=0x1006b71a0 cpplib, msgid=0x1006b71d0 error: ) at ../../gcc-4.1-20050917/intl/dgettext.c:54 54 } (gdb) _cpp_begin_message (pfile=Variable pfile is not available. ) at ../../gcc-4.1-20050917/libcpp/errors.c:125 125 } (gdb) 120 fputs (_(internal error: ), stderr); (gdb) Program received signal SIGSEGV, Segmentation fault. 0x7f23d28c in strlen () from /usr/lib/64/libc.so.1 if I set the environment variable LANG to C (previously unset), it works: sparc% setenv LANG C sparc% gcc -E -dH test.c test.i gcc: test.c: No such file or directory gcc: no input files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-09-23 21:35 --- I can't explain it, but on today's mainline, this bug does not appear. I'm going to commit the smaller test case (... make_k ...) from above to libmudflap/testsuite. If this test fails, please post an attachment with the error log. Since neither my x86 nor x86-64 machine shows the problem, it may be necessary for you to rebuild the test case with extra dump flags (-fdump-tree-all and friends) and scour through that for clues. -- What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 21:35 --- Subject: Bug 19319 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 21:35:17 Modified files: libmudflap : ChangeLog Added files: libmudflap/testsuite/libmudflap.c++: pass58-frag.cxx Log message: 2005-09-23 Frank Ch. Eigler [EMAIL PROTECTED] * testsuite/libmudflap.c++/pass58-frag.cxx: New test for heisenbug 19319. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/ChangeLog.diff?cvsroot=gccr1=1.71r2=1.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/testsuite/libmudflap.c++/pass58-frag.cxx.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug translation/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 21:53 --- Can you give the output of env before setting LANG? -- What|Removed |Added Component|preprocessor|translation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug translation/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From heas at shrubbery dot net 2005-09-23 21:56 --- Subject: Re: cpp segfaults when a non-existent include is encountered Fri, Sep 23, 2005 at 09:53:33PM -, pinskia at gcc dot gnu dot org: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 21:53 --- Can you give the output of env before setting LANG? USER=root LOGNAME=root HOME=/home/heas PATH=/usr/pkg/bin:/usr/pkg/sbin:/home/heas/bin:/usr/local/bin:/usr/bin:/usr/ccs/bin:/usr/sbin:/usr/openwin/bin:/usr/ucb MAIL=/var/mail//heas SHELL=/bin/tcsh TZ=UTC SSH_CLIENT=198.58.5.2 64591 22 SSH_CONNECTION=198.58.5.2 64591 198.58.5.71 22 SSH_TTY=/dev/pts/3 TERM=xterm DISPLAY=localhost:12.0 HOSTTYPE=sun4 VENDOR=sun OSTYPE=solaris MACHTYPE=sparc SHLVL=2 PWD=/home/pkgsrc GROUP=root HOST=yew REMOTEHOST=maple.shrubbery.net UNAME=/bin/uname CVSROOT=/home/heas/.CVS CVS_RSH=ssh RSYNC_RSH=ssh CLOGIN=x TMPDIR=/tmp PRINTER=lp PAGER=less MANPATH=/usr/pkg/man:/home/ops/man:/usr/local/man:/usr/man:/usr/local/X11/man:/usr/local/gnu/man EDITOR=/usr/ucb/vi VISUAL=/usr/ucb/vi PGPPATH=/home/heas/.pgp SUDO_COMMAND=/usr/pkg/bin/tcsh SUDO_USER=heas SUDO_UID=7053 SUDO_GID=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug libmudflap/23084] mudflap crash upon accept() with argement 2 and 3 as NULL
--- Additional Comments From fche at redhat dot com 2005-09-23 21:58 --- patch committed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23084
[Bug libmudflap/23084] mudflap crash upon accept() with argement 2 and 3 as NULL
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 21:58 --- Subject: Bug 23084 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 21:58:42 Modified files: libmudflap : ChangeLog mf-hooks2.c Log message: 2005-09-23 Frank Ch. Eigler [EMAIL PROTECTED] PR 23084. * mf-hooks2.c (accept): Tolerate NULL sockaddr* parameter. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/ChangeLog.diff?cvsroot=gccr1=1.72r2=1.73 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/mf-hooks2.c.diff?cvsroot=gccr1=1.14r2=1.15 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23084
[Bug c++/24046] New: Inheriting from a base class with private scoped operator new/delete pair
There is a gcc 2.95.3 compiler bug where inheriting from a base class with a
private 'operator delete' (and its matching partner 'operator new') complains
and bails. Privitizing class specific operator new/delete pair is a common idom
to prevent freestore allocation. This is fixed in later version of gcc.
1 #include sys/types.h
2
3 class Base
4 {
5 public:
6 Base() {}
7 ~Base() {}
8 private:
9 // Prevent allocation on freestore -- privitize op new/delete
10 static void* operator new (size_t size);
11 static void operator delete(void*);
12 };
13
14 class Derived : public Base
15 {
16 public:
17 Derived() {}
18 ~Derived() {}
19 };
% gcc -save-temps -Wall baseopdelete.cpp
baseopdelete.cpp: In method `Derived::~Derived()':
baseopdelete.cpp:11: `static void Base::operator delete(void *)' is private
baseopdelete.cpp:18: within this context
--
Summary: Inheriting from a base class with private scoped
operator new/delete pair
Product: gcc
Version: 2.95.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richy at fatkid dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: Linux 2.4.29
GCC target triplet: 2.95.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24046
[Bug c++/24046] Inheriting from a base class with private scoped operator new/delete pair
--- Additional Comments From richy at fatkid dot org 2005-09-23 22:02 --- Created an attachment (id=9797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9797action=view) baseopdelete.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24046
[Bug other/20128] ice with mudflap + profile generate
--- Additional Comments From pluto at agmk dot net 2005-09-23 22:03 --- still ICEs with current mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug c++/24046] Inheriting from a base class with private scoped operator new/delete pair
--- Additional Comments From richy at fatkid dot org 2005-09-23 22:03 --- % gcc -v Reading specs from /opt/third-party/depot/Linux-2.4c2.2-i686/gcc-2.95.3/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24046
[Bug c++/24046] Inheriting from a base class with private scoped operator new/delete pair
--- Additional Comments From richy at fatkid dot org 2005-09-23 22:04 --- Created an attachment (id=9798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9798action=view) baseopdelete.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24046
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-23 22:05 --- PR 19870. Although these patches are largeish, they have been tested in HEAD for some time and should be pretty safe. They are needed for OO.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug c++/24046] Inheriting from a base class with private scoped operator new/delete pair
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 22:05 --- Yes 2.95.3 is 4 years old and have not been maintined for about 4 years now. This was fixed in 3.0 which also stoped being maintained for 3 years. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to fail||2.95.3 Known to work||3.0.4 3.3.3 3.4.0 4.0.0 ||4.1.0 Resolution||FIXED Target Milestone|--- |3.0.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24046
[Bug translation/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 22:10 --- Hmm, I still cannot reproduce this with LANG set to nothing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug translation/24039] cpp segfaults when a non-existent include is encountered
--- Additional Comments From heas at shrubbery dot net 2005-09-23 22:18 --- Subject: Re: cpp segfaults when a non-existent include is encountered Fri, Sep 23, 2005 at 10:10:12PM -, pinskia at gcc dot gnu dot org: Hmm, I still cannot reproduce this with LANG set to nothing. I think that I mis-spoke in my excitment; it still fails with LANG set. In the example that I sent, I was in the wrong directory, where test.c did not exist. sorry. I will poke some more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24039
[Bug c++/22406] -Weffc++ warns about missing op= and copy ctor, even when base classes have already disabled these
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 22:26 --- Hmm, I get only warning for this code: t.cc:10: warning: base class class Foo has a non-virtual destructor -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22406
[Bug c++/13005] Pointer adjusted for derived class containing virtual function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 22:34 --- Note did you post your patch to [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13005
