Re: Support for the MPC5554 in gcc ?
Hello, To: Can GCC 4.X be used to generate code running properly on a MPC5554 processor ? [...] What are the GCC 3.4 capabilities on the same account ? David Edelsohn replied: The base PowerPC Book-E UISA generated by GCC should work on the MPC5554. I am not sure about the difference between the 5554 e200 core and the 8540 e500 core. Kumar Gala at Freescale probably can provide more details about compatibility with GCC's e500 support and support in previous GCC releases. Then Clemens Koller: I've just compiled and installed the official gcc-3.4.4 release as a native compiler on an MPC8540 like that: [...] and Oh, i've just seen that: http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf The e200z6, implemented in the MPC5556 microcontroller, is code-compatible with +e500 core (including isel, SPE, and single-precision floating-point APUs). This all was very useful feeback, much appreciated, thanks a lot :) With Kind Regards, Olivier
software floating point machine descriptions
Hi, gcc I have to send the new mail again for the software floating point problem. I need more details about it. 1) If I use software floating point, does I need implement float mode insns in md file? Such as movsf, movdf. 2)How to generate correct object files of libgcc2 of floating point operations? Such as _floatdidf. Thank you very much. Eric.
failed to build libgfortran gcc-4.0.1 on mips-sgi-irix6.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/xgcc - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/ - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/ - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/lib/ - -isystem /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/include - -isystem /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/sys-include - -DHAVE_CONFIG_H -I. - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran - -I. - -iquote/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/io - -std=gnu99 -Wall -O2 -g -O2 -mabi=32 -c /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c - -o exp_c8.o /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c:38: error: conflicting types for 'cabs' /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/include/math.h:676: error: previous declaration of 'cabs' was here configured with: /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/configure - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld - --disable-shared --enable-threads=single --enable-haifa --disable-nls - --disable-libmudflap --enable-languages=c,ada,c++,f95,objc - --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDJUuZ3s6elE6CYeURAvphAJ41Q+V9wtWZG70nNPfgsTZu5UlKdgCgx2WI AILkpLglpO1tFjNc5VkQWEI= =tJPb -END PGP SIGNATURE-
Re: sh64 support deteriorating
Richard Henderson wrote: On Fri, Sep 09, 2005 at 04:58:50PM +0100, Joern RENNECKE wrote: The lack of a debugger that works reliably with recent gcc versions has led to an increasing backlog of uninvestigated execution failures. Do you think it's the debugger or the compiler that's at fault? The debugger crashes when certain (recently pretty much any) debug information is enclosed. Thus, the debugger is at fault, for crashing. But for all I know, the compiler might also be at fault, for emitting invalid debug information; however it is more likely newer debug information that my vintage gdb can't understand. The execution failures are most likely gcc bugs, except when prefetching unmapped memory is involved; the simulator had a bug there.
Re: zero sized initializers with side effects discarded
Andrew Pinski wrote: FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not set on the constructor, despite the presence of a function call in the components. No, that is not the problem. The problem is that we gimplify the expression for side effects but don't actually add the expression if the gimplify put it back in the same expression. Any ways, the following patch fixes the issue correctly. If you could test and post the patch, that would be nice? Will look into it as a separate change (from the init_ctor that I'm about to submit). Thanks.
SH patch applied (Was: Re: sh64 support deteriorating)
Kaz Kojima wrote:
some compile time errors in c/c++ test for sh64-unknown-linux-elf
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00466.html
3 tests
gcc.c-torture/compile/simd-4.c
gcc.c-torture/execute/20050604-1.c
gcc.dg/torture/pr21817-1.c
fail with the similar ICE:
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c: In function 'tempf':
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: unable to find a
register to spill in class 'GENERAL_REGS'
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: this is the insn:
(insn 53 52 54 0 (set (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(and:DI (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(const_int -4294967296 [0x]))) 85 {anddi3} (nil)
(nil))
Yes, these appeared also in the simulator tests.
It seems odd that the DImode subregs of V4SFmode registers are used
as the operands of logical operations, though I don't understand why
reload complains as above.
reload complained because HARD_REGNO_MODE_OK disallowed
V4SFmode in GENERAL_REGS. Allowing that also causes register
allocation to use GENERAL_REGS in the first place. An and with a
J16 constraint can also be done with FP_REGS using mov.ls from r63.
A natural way to implement this would use an fr (or rf) constraint in
one of the alternatives. While looking at this I also found that we were
missing a register class for an fr constraint. I've tested the attached
patch over the weekend for sh-elf and sh64-elf, and checked it in now.
2005-09-12 Jorn Rennecke [EMAIL PROTECTED]
* sh.h (HARD_REGNO_MODE_OK): Allow V4SFmode in general purpose
registers for TARGET_SHMEDIA.
(enum reg_class, REG_CLASS_NAMES, REG_CLASS_CONTENTS): Rename
GENERAL_FP_REGS to GENERAL_DF_REGS. Add GENERAL_FP_REGS as union
of GENERAL_REGS and FP_REGS.
Index: sh.h
===
RCS file: /cvs/gcc/gcc/gcc/config/sh/sh.h,v
retrieving revision 1.276
diff -p -r1.276 sh.h
*** sh.h6 Aug 2005 13:26:24 - 1.276
--- sh.h12 Sep 2005 13:21:53 -
*** extern char sh_additional_register_names
*** 1152,1158
|| GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V4SFmode \
? ((FP_REGISTER_P (REGNO) ((REGNO) - FIRST_FP_REG) % 4 == 0) \
! || (! TARGET_SHMEDIA GENERAL_REGISTER_P (REGNO))) \
: (MODE) == V16SFmode \
? (TARGET_SHMEDIA \
? (FP_REGISTER_P (REGNO) ((REGNO) - FIRST_FP_REG) % 16 == 0) \
--- 1152,1158
|| GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V4SFmode \
? ((FP_REGISTER_P (REGNO) ((REGNO) - FIRST_FP_REG) % 4 == 0) \
! || GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V16SFmode \
? (TARGET_SHMEDIA \
? (FP_REGISTER_P (REGNO) ((REGNO) - FIRST_FP_REG) % 16 == 0) \
*** enum reg_class
*** 1341,1346
--- 1341,1347
DF_REGS,
FPSCR_REGS,
GENERAL_FP_REGS,
+ GENERAL_DF_REGS,
TARGET_REGS,
ALL_REGS,
LIM_REG_CLASSES
*** enum reg_class
*** 1365,1370
--- 1366,1372
DF_REGS, \
FPSCR_REGS, \
GENERAL_FP_REGS, \
+ GENERAL_DF_REGS, \
TARGET_REGS, \
ALL_REGS, \
}
*** enum reg_class
*** 1402,1408
/* FPSCR_REGS: */\
{ 0x, 0x, 0x, 0x, 0x0080 }, \
/* GENERAL_FP_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0102ff00 }, \
/* TARGET_REGS: */ \
{ 0x, 0x, 0x, 0x, 0x00ff }, \
/* ALL_REGS: */ \
--- 1404,1412
/* FPSCR_REGS: */\
{ 0x, 0x, 0x, 0x, 0x0080 }, \
/* GENERAL_FP_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0302 }, \
! /* GENERAL_DF_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0302ff00 }, \
/* TARGET_REGS: */ \
{ 0x, 0x, 0x, 0x, 0x00ff }, \
/* ALL_REGS: */ \
Re: Retested: RFA: fix PR middle-end/23290
Thanks for the review. Richard Henderson wrote: Though I'll state again for the record that any ABI that bases its decisions on modes instead of tree codes is broken. The specific mode that was tested against was BLKmode. If we want to make ports impervious to random use of BLKmode, we should declare the practice of FUNCTION_ARG yielding a REG rtx as obsolete, i.e. everything but a plain stack argument has to be expressed with a PARALLEL. At the moment, tm.texi still states that a value not passes on the stack is usually expressed with a REG rtx, and these can't handle BLKmode.
New port contribution - picoChip
Hi all, For the past 4 years or so I have maintained a port of gcc for the range of embedded processors developed by picoChip Designs Ltd. I would now like to formally contribute this port. Key points to note are: Assignment forms have been filed with the FSF. I have obtained cvs-write permission. All work listed in `Anatomy of a Target Back End' has been completed, with the exception of web page updates. The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. Custom test procedures are used, which don't currently work with DejaGNU. This will be fixed at some point. The port is almost independent of any other changes to gcc. When my port was based upon 3.4.0 it relied on a patch in sched-deps.c, but the patch was never applied to mainline (http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00598.html). I have now upgraded my port to the current mainline (4.1.0 20050912), and all of my regression tests which exposed the original bug now pass, with no need for the patch. From inspecting the code, I believe that another bug fix I recently applied to my port (http://gcc.gnu.org/ml/gcc/2005-09/msg00088.html) fixes the problem indirectly. Assuming that my port doesn't require a patch in sched-deps.c, can I submit this port to gcc in time for the 4.1 branch, or must I wait until afterwards? If I was allowed to submit before the branch, what would the deadline be? Thanks, dan. = Daniel Towner picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] http://www.picochip.com +44 (0) 7786 702589
Re: New port contribution - picoChip
Daniel Towner writes: Daniel Assuming that my port doesn't require a patch in sched-deps.c, can I Daniel submit this port to gcc in time for the 4.1 branch, or must I wait Daniel until afterwards? If I was allowed to submit before the branch, what Daniel would the deadline be? GCC development allows a lot of leeway to new ports and port-specific changes that do not require changes to the common parts of the compiler. The GCC development plan would allow the port to be accepted for GCC 4.1, the new port needs to be reviewed by a GWP maintainer. David
Any plan to support Windows/x86-64?
Is there any plan to support Windows/x86-64? What are needed for the port? H.J.
Re: New port contribution - picoChip
On Monday 12 September 2005 18:55, Giovanni Bajo wrote: Daniel Towner [EMAIL PROTECTED] wrote: The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. I suppose this means that nobody but you will ever be able to run/test your backend. If you are fine with this, I don't think anybody will object. I think people should object. What is the point in having a free software compiler if e.g. users can't use a complete free toolchain; or gcc developers not being able to test changes when some patch needs changes in every port. Gr. Steven
RE: New port contribution - picoChip
Original Message From: Steven Bosscher Sent: 12 September 2005 18:01 On Monday 12 September 2005 18:55, Giovanni Bajo wrote: Daniel Towner daniel.towner wrote: The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. I suppose this means that nobody but you will ever be able to run/test your backend. If you are fine with this, I don't think anybody will object. I think people should object. What is the point in having a free software compiler if e.g. users can't use a complete free toolchain; or gcc developers not being able to test changes when some patch needs changes in every port. Gr. Steven I second that. I'd feel differently if there was at least a FOSS simulator around that people could directly run the assembler output on, but as it stands it seems like adding this backend is a burden to the community for zero benefit. I have to ask Dan: *Why* do you want to contribute this port? Cui bono? cheers, DaveK -- Can't think of a witty .sigline today
Re: New port contribution - picoChip
Daniel Towner [EMAIL PROTECTED] wrote: The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. On Mon, Sep 12, 2005 at 06:55:28PM +0200, Giovanni Bajo wrote: I suppose this means that nobody but you will ever be able to run/test your backend. If you are fine with this, I don't think anybody will object. Daniel wrote at this point. Presumably they will eventually be made available. Even if they are forever proprietary, others would be able to port the GNU assembler and linker at a later time.
Re: New port contribution - picoChip
Steven Bosscher [EMAIL PROTECTED] wrote: The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. I suppose this means that nobody but you will ever be able to run/test your backend. If you are fine with this, I don't think anybody will object. I think people should object. What is the point in having a free software compiler if e.g. users can't use a complete free toolchain; or gcc developers not being able to test changes when some patch needs changes in every port. You can still test compilation, at least. I think it makes sense as an intermediate step, assuming the port of binutils is in the works. Usually first binutils is contributed, but hey. -- Giovanni Bajo
Re: New port contribution - picoChip
A similar issue was raised last Spring and discussed by the GCC Steering Committee. Mark Mitchell summarized the response, including Richard Stallman's comment: http://gcc.gnu.org/ml/gcc/2005-06/msg00134.html There is no need to resurrect that debate. David
RE: New port contribution - picoChip
Original Message From: David Edelsohn Sent: 12 September 2005 19:00 A similar issue was raised last Spring and discussed by the GCC Steering Committee. Mark Mitchell summarized the response, including Richard Stallman's comment: http://gcc.gnu.org/ml/gcc/2005-06/msg00134.html There is no need to have a uniform policy about it. There is no compelling reason to treat all such cases alike. There is no need to resurrect that debate. I will not post to this thread again. Everyone else can do as they please AFAIC. cheers, DaveK -- Can't think of a witty .sigline today
Re: uncaught exception in g++ 3.4 and 4.0
Andrew Haley wrote:
There's a thread at
http://groups.google.co.uk/group/gnu.gcc.help/tree/browse_frm/thread/e85dce7d69fb7dc1
which looks odd. It seems that the exception filter is not being
correctly processed.
I can't find a Bugzilla entry for this. Is it really a bug?
Andrew.
quoted message
From: Mark Nelson [EMAIL PROTECTED]
Newsgroups: gnu.gcc.help
Subject: uncaught exception in g++ 3.4 and 4.0
Date: 13 Aug 2005 08:35:46 -0700
I have a case where an exception in the constructor of class with a
virtual base leads to termination:
struct vbase {};
struct foo : virtual vbase {
foo() {
throw exception in foo ctor;
}
};
main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};
This program demonstrates the problem in g++ 3.4 a 4.0.0. Instead of
catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.
That should be a clue... but I'm unable to catch it.
The exception should be caught. The destructor for vbase should be run,
but the destructors for foo and bar should not be, as foo was never
completely constructed. Then, the catch-clause should run, and the
program should return 0.
I suspect the bug is in the logic for computing the exception
specification for the implicitly-defined bar::bar() constructor. It
should allow all exceptions, since the base class constructor does.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: New port contribution - picoChip
On Sep 12, 2005, at 8:32 AM, Daniel Towner wrote: I would now like to formally contribute this port. The way to do that is to send an email to gcc-patches, with the port. :-) You can also volunteer to maintain the port at the same time, if you so choose.
Re: New port contribution - picoChip
On 12 Sep 2005, Steven Bosscher gibbered uncontrollably: I think people should object. What is the point in having a free software compiler if e.g. users can't use a complete free toolchain; or gcc developers not being able to test changes when some patch needs changes in every port. Well, that kills HP-UX and Tru64 and many other targets. A *lot* of targets don't have free-software linkers, in particular. -- `One cannot, after all, be expected to read every single word of a book whose author one wishes to insult.' --- Richard Dawkins
Separating c++ parser
Hi all, I intend to use gcc's C++ parser and the intermediate representation it creates for use in source browsing, etc. I have a few questions regarding this: firstly, is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? If so, can somebody offer hints on where I could start? I am currently looking into the gcc/cp front-end subdirectory, but clearly, there are a number of dependencies inside the main gcc code as well. The other question is: the build process for gcc is quite hairy - stage1, etc. etc. Since I am not concerned with code generation or optimization at all, I don't think I would need this. How would I begin simplifying the auto* and Makefile.in's to allow building the parser as a stand-alone entity? Thanks in advance for any help or pointers! Ashwin -- Ashwin Bharambe, Ph.D. Candidate, Carnegie Mellon University. Office: 412-268-7555Web: http://www.cs.cmu.edu/~ashu
Re: Separating c++ parser
On 09/12/05 15:30, Ashwin Bharambe wrote: is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? Not really. Though we have been re-designing the internal architecture to be more modular, all the components are meant to be used together. At most, you could plug your own transformation/analysis inside the compiler.
Re: Separating c++ parser
Hmm. Ok fine, I can live with having to keep all extraneous code lying around. But it seems like there must be a way to: - stop gcc once the cp frontend parses the code and generates the parse tree structure. - disable the stage1,stage2 compilation etc. during the build process? Or, is there something I am still missing? :) Thanks, Ashwin On 9/12/05, Diego Novillo [EMAIL PROTECTED] wrote: On 09/12/05 15:30, Ashwin Bharambe wrote: is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? Not really. Though we have been re-designing the internal architecture to be more modular, all the components are meant to be used together. At most, you could plug your own transformation/analysis inside the compiler. -- Ashwin Bharambe, Ph.D. Candidate, Carnegie Mellon University. Office: 412-268-7555Web: http://www.cs.cmu.edu/~ashu
Re: Separating c++ parser
On Mon, 12 Sep 2005, Ashwin Bharambe wrote: - disable the stage1,stage2 compilation etc. during the build process? IIRC cross-compilers do not use stage1/2/3 as it is not possible to execute produced target binary on the host platform. And for compiling cross-compiler simple `make' is used. So I would recommend the same instead of `make bootstrap' Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Separating c++ parser
On 09/12/05 15:55, Ashwin Bharambe wrote: - stop gcc once the cp frontend parses the code and generates the parse tree structure. Check -fsyntax-only. - disable the stage1,stage2 compilation etc. during the build process? just do 'make all' instead of 'make bootstrap'.
Re: software floating point machine descriptions
Eric Fisher [EMAIL PROTECTED] writes: I have to send the new mail again for the software floating point problem. I need more details about it. 1) If I use software floating point, does I need implement float mode insns in md file? Such as movsf, movdf. You do have to implement movsf and movdf, yes. You do not have to implement insns for floating point operations. 2)How to generate correct object files of libgcc2 of floating point operations? Such as _floatdidf. Look at, e.g., config/mips/t-mips. Ian
Re: Minimum/maximum operators are deprecated?
Giovanni Bajo [EMAIL PROTECTED] writes: Steven Bosscher [EMAIL PROTECTED] wrote: It was an ill-defined and poorly maintained language extension that was broken in many cases. That's an overstatement. I've been using it for years without any problem, and was very deprived by its removal, though I can understand the we don't want extensions reason. But that's really the only compelling one that prompted its removal. It's quite common that extensions work just fine except maybe for a few rare cases for some people and are horribly broken with severe design flaws for other people. This follows the 99% rule of compiler design, which is that if a design 99% works, you'll get 100% more bug reports from 1% of your users.
Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
Greetings. I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. I am using binutils-2.16.1, a checkout of gcc-4.1 from 20050604 and uClibc. Has anyone else seen something like this? My compile and link lines look like the following: /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux-uclibc-gcc -Wall -Wstrict-prototypes -O0 -mno-split-addresses -g -c clone.c -o clone.o /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux-uclibc-gcc -g -Wl,-warn-common -static clone.o -o clone I can post binaries if desired. Thanks. -Steve
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
On Sep 12, 2005, at 7:17 PM, Steven J. Hill wrote: Greetings. I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. I am using binutils-2.16.1, a checkout of gcc-4.1 from 20050604 and uClibc. Has anyone else seen something like this? My compile and link lines look like the following: /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -Wall -Wstrict-prototypes -O0 -mno-split-addresses -g - c clone.c -o clone.o /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -g -Wl,-warn-common -static clone.o -o clone I've not seen it, but do you see it with, say, those options and the simulator testsuite? (I don't have one built at the moment or I'd check myself.) Otherwise, what's the code look like where they segfault? -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
Eric Christopher wrote: I've not seen it, but do you see it with, say, those options and the simulator testsuite? (I don't have one built at the moment or I'd check myself.) I assume you mean using the gdb simulator, or what? Sorry for my ignorance. Otherwise, what's the code look like where they segfault? Let me quantify that and I will post a tarball tomorrow. Thanks. -Steve
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
I assume you mean using the gdb simulator, or what? Sorry for my ignorance. Yup. Otherwise, what's the code look like where they segfault? Let me quantify that and I will post a tarball tomorrow. Thanks. OK. I don't have any mips hardware at the moment, but I should be able to help you anyhow :) -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
On Mon, Sep 12, 2005 at 09:17:57PM -0500, Steven J. Hill wrote: I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. While it is possible that the toolchain is at fault, it is also possible that it is a program bug. Sometimes memory corruption can look like this: if you have an uninitialized pointer, trash the heap, etc. it can have different effects depending on optimization level. Even the size of your environment can have an effect. You might want to first make sure that your program has no memory access errors. You could try building it for x86 and debugging with valgrind, to see if that catches anything.
[Bug middle-end/19419] Overlapping memcpy with discriminated types
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12 06:14 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-15 21:34:21 |2005-09-12 06:14:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19419
[Bug middle-end/19410] Overlapping memcpy with big struct copies
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12
07:12 ---
Here are 2 equivalent testcases in Ada and C:
procedure p is
SUBTYPE INT IS INTEGER RANGE 0..1000;
TYPE RECTYPE (CONSTRAINT : INT := 80) IS
RECORD
INTFIELD : INTEGER;
STRFIELD : STRING (1..CONSTRAINT);
END RECORD;
REC1 : RECTYPE(1000);
PROCEDURE COPY_RECTYPE (REC : OUT RECTYPE) is
begin
REC := REC1;
end;
begin
COPY_RECTYPE (REC1);
end;
struct A
{
int a[1024];
};
struct A my_a;
void g(struct A *a)
{
*a = my_a;
}
int main(void)
{
g(my_a);
}
The call to memcpy is hard-wired in the middle-end (expr.c:1390):
void
init_block_move_fn (const char *asmspec)
{
if (!block_move_fn)
{
tree args, fn;
fn = get_identifier (memcpy);
args = build_function_type_list (ptr_type_node, ptr_type_node,
const_ptr_type_node, sizetype,
NULL_TREE);
fn = build_decl (FUNCTION_DECL, fn, args);
DECL_EXTERNAL (fn) = 1;
TREE_PUBLIC (fn) = 1;
DECL_ARTIFICIAL (fn) = 1;
TREE_NOTHROW (fn) = 1;
block_move_fn = fn;
}
I still don't plan to work on this in the near future.
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410
[Bug middle-end/19419] Overlapping memcpy with discriminated types
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12 07:25 --- I agree with Andrew, the call to __builtin_memcpy is present in t03.gimple but not in t02.original and is hard-wired in gimplify_modify_expr_to_memcpy: to_ptr = build_fold_addr_expr (to); args = tree_cons (NULL, to_ptr, args); t = implicit_built_in_decls[BUILT_IN_MEMCPY]; t = build_function_call_expr (t, args); -- What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19419
[Bug ada/19037] constant renaming creates new constant
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12 07:53 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-06-16 22:44:08 |2005-09-12 07:53:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19037
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 08:10 --- The testcase is definitely too large and trying to create a simple two-file based one didn't work out to reproduce the problem. If it changes calling-conventions in single-file compile mode the function must be declared static, so it definitely may be changed in whole-program mode, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug c++/23823] Is this right?
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 08:15 --- It could say, instead of foo.cc:13: error: partial specialization `gT, true' of function template rather foo.cc:13: error: partial specialization `gT, true' of function template not allowed to make it clear that the following errors are just other ways of saying the above. -- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug fortran/18899] [gfortran] ubound wrongly calculated for passed array
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-12 08:51 --- About to post a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-10 14:51:18 |2005-09-12 08:51:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18899
[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 08:55 --- Max memory usage on (checking-disabled) mainline is now 253149kB (on a machine with 1GB of RAM) for C and 403669kB for C++ (!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug target/23831] New: ICE in immed_double_const with vectorized multipication
This testcase ICEs with -O2 -msse2 -ftree-vectorize:
void
test_1 (void)
{
static unsigned int bm[16];
int j;
for (j = 0; j 16; j++)
bm[j] = bm[j] * 8;
}
prxxx.c: In function 'test_1':
prxxx.c:8: internal compiler error: in immed_double_const, at emit-rtl.c:468
[BTW: This bug was found when dealing with PR target/22480. As a nice
enhancement, this code should actually be transformed into vector left shift by
3.]
--
Summary: ICE in immed_double_const with vectorized multipication
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, ssemmx
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
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=23831
[Bug tree-optimization/23817] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-12 09:32 --- Patch. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00706.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 09:44 --- Subject: Bug 23767 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 09:42:36 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_iterator.h Added files: libstdc++-v3/testsuite/23_containers/vector/types: 23767.cc libstdc++-v3/testsuite/21_strings/basic_string/types: 23767.cc libstdc++-v3/testsuite/ext/vstring/types: 23767.cc Log message: 2005-09-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/23767 * include/bits/stl_iterator.h (__normal_iterator:: __normal_iterator(const __normal_iterator_Iter, _Container)): Enable only when _Iter is equal to _Container::pointer. * testsuite/21_strings/basic_string/types/23767.cc: New. * testsuite/23_containers/vector/types/23767.cc: Likewise. * testsuite/ext/vstring/types/23767.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3096r2=1.3097 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_iterator.h.diff?cvsroot=gccr1=1.28r2=1.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector/types/23767.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/types/23767.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/ext/vstring/types/23767.cc.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-12 09:45 --- Fixed for 4.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-12 09:46 --- Fixed for 4.1. -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 10:03 --- One problem is that we use integer tree nodes for counting from zero to N, which is just stupid and wastes RAM (because we do not collect during building the initializer). Of course we also store that index in the initializer element list. This whole mess asks for a (less general) rewrite. Minimal-invasive surgery is impossible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays
--- Additional Comments From giovannibajo at libero dot it 2005-09-12 10:08 --- The problem is that the gimplifier always want the index field of the constructor element to be filled. If you fix that in the obvious way (so that no index means previous index + 1), it should be quite easy to fix, for C++. In C, I have no clue how this interacts with designated initializers though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From T dot Farago at lumc dot nl 2005-09-12 10:13 --- Ah great for fixing this, will try out as soon as the latest snapshot comes. I had the problem that was present in comment #17, just Fortran, no C-Fortran mix. It must have been some kind of regression (at least for libfortran) because it worked in the 4.0.0 release when we first tried it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 10:52 --- The second testcase works for me on current mainline if adding a class UltraRoot forward declaration at the top. It takes around 1m30 to compile and uses up max. 522913kB of memory (1GB box, P4 2.8GHz) at -O2. Still aliasing accounts for the most time: samples %image name symbol name 694 26.6411 cc1plus add_stmt_operand 209 8.0230 cc1plus ldst_entry 193 7.4088 cc1plus create_ssa_artficial_load_stmt 181 6.9482 cc1plus compute_global_livein 572.1881 cc1plus bitmap_bit_p 501.9194 no-vmlinux (no symbols) 451.7274 cc1plus compute_may_aliases 421.6123 cc1plus invalidate 361.3820 cc1plus bitmap_ior_and_compl_into 351.3436 cc1plus bitmap_set_bit 351.3436 cc1plus for_each_rtx_1 331.2668 cc1plus check_dependence 291.1132 cc1plus splay_tree_splay_helper 281.0749 cc1plus htab_find_slot_with_hash The 2nd is from GCSE, 3rd from DOM, 4th from either into-ssa or ssa-loop-manip. Time-report: tree SSA incremental : 14.27 (17%) usr 0.11 ( 3%) sys 14.46 (16%) wall 12827 kB ( 2%) ggc tree operand scan : 15.62 (18%) usr 0.27 ( 8%) sys 15.93 (18%) wall 59212 kB (10%) ggc dominator optimization: 8.67 (10%) usr 0.05 ( 1%) sys 8.64 (10%) wall 110089 kB (19%) ggc PRE : 6.14 ( 7%) usr 0.01 ( 0%) sys 6.13 ( 7%) wall 536 kB ( 0%) ggc ldst_entry is walking a list to find an element by hash-id. Throw some memory at it to add a real hashtable for lookup besides the list. The DOM stuff looks like value numbering still in DOM, hopefully it will be ripped out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug fortran/20405] [meta-bug] equivalenced variable problems
-- Bug 20405 depends on bug 15382, which changed state. Bug 15382 Summary: frontend too lenient when checking variable declarations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15382 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/15382] frontend too lenient when checking variable declarations
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-12 11:06 --- [EMAIL PROTECTED]:~/src/tests ../gcc/build/gcc/f951 pr15083.f90 In file pr15083.f90:4 REAL :: Y = 1. 1 Error: Initializer not allowed for COMMON variable 'y' at (1) Execution times (seconds) TOTAL : 0.01 0.00 0.02 533 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. [EMAIL PROTECTED]:~/src/tests This was fixed by Paul Thomas' recent patches for commons and equivalences. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15382
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18870, which changed state. Bug 18870 Summary: [g77 regression] Equivalencing two common blocks is not caught http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18870 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED Bug 19292 depends on bug 15382, which changed state. Bug 15382 Summary: frontend too lenient when checking variable declarations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15382 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-12 11:18 --- (In reply to comment #21) It must have been some kind of regression (at least for libfortran) because it worked in the 4.0.0 release when we first tried it. This bug was introduced while fixing another bug. This will now work on both branches, including 4.0.2 (to be released soon). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug target/23832] New: libjava build failure on sh64
libjava build on sh64-uknown-linux-gnu fails with: /ext3/suzaku/home/kkojima/xsh-gcc/gcc/gcj -B/ext3/suzaku/home/kkojima/xsh-gcc/sh64-unknown-linux-gnu/libjava/ -B/ext3/suzaku/home/kkojima/xsh-gcc/gcc/ -mieee -fclasspath= -fbootclasspath=/ext3/suzaku/home/kkojima/xsh-gcc/sh64-unknown-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -MT javax/swing/plaf/basic.lo -MD -MP -MF javax/swing/plaf/basic.deps @javax/swing/plaf/basic.list -fPIC -o javax/swing/plaf/.libs/basic.o ../../../LOCAL/gcc/libjava/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java: In class 'javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout': ../../../LOCAL/gcc/libjava/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java: In method 'javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateSize(boolean)': ../../../LOCAL/gcc/libjava/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java:214: internal compiler error: Segmentation fault It started to fail at 20050827 and the segfault occurs in insn-recog.c at the code like ... tem = peep2_next_insn (2); x1 = PATTERN (tem); ... where peep2_next_insn returns (pc) which is the PEEP2_EOB marker. -- Summary: libjava build failure on sh64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org 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: sh64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23832
[Bug tree-optimization/17790] [4.0/4.1 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-12 12:02 --- Current mainline with -O3 -funroll-loops daten.f takes 3.6s to compile. loop invariant motion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree canonical iv : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 8 kB ( 0%) ggc Multiple compilations finally produce an evenly distributed profile: samples %image name symbol name 914.8097 no-vmlinux (no symbols) 321.6913 f951 cse_insn 291.5328 f951 count_reg_usage 281.4799 f951 mark_set_1 261.3742 f951 constrain_operands 231.2156 f951 bitmap_bit_p 221.1628 f951 find_reg_note 221.1628 f951 init_alias_analysis 201.0571 f951 for_each_rtx_1 191.0042 f951 invalidate -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-12
12:35 ---
reduced testcase, also failing with -O2 -fnon-call-exceptions
void run (void) {
float stack[1];
*(stack - 1) = 0.0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-12 12:41 --- The problem is that the array is mapped to a single SFmode register. One could probably replace the assert with a run-time invocation of abort(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug c++/23823] Is this right?
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-12 12:42 --- Subject: Re: Is this right? igodard at pacbell dot net wrote:- --- Additional Comments From igodard at pacbell dot net 2005-09-12 03:17 --- In the case you give I count one template argument specificatiob, and two template parameters. Your understanding of the meaning of parameter and argument is backwards, which is probably the source of your confusion. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug c++/23823] Is this right?
--- Additional Comments From igodard at pacbell dot net 2005-09-12 12:48 --- Neil - Backwards no doubt! I'm sure that any programmer who has studied the formal syntax of C++ will have it correctly forwards. For the remaining 99.95% of programmers (who like me tend to use parameter and argument somewhat interchangably) a little help in the diagnostic would be a welcome blessing. Of course, if the target audience for gcc is the developers that work on it, then the present message is just fine... Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug c++/23825] [4.0/4.1 Regression] Extra C++ failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 13:10 --- Fixed by: * decl2.c (build_anon_union_vars): Copy attributes from the base addr. * pt.c (tsubst_decl): Substitute in DECL_VALUE_EXPR. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23825
[Bug c++/23833] New: warning: ignoring packed attribute on unpacked non-POD field on templates
gcc ver 3.4.3 system type: any g++ -v -save-temps -Wall test.cpp i see bug 17519 but this can be other bug. -- Summary: warning: ignoring packed attribute on unpacked non-POD field on templates Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dmitry dot Chepel at acronis dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: ignoring packed attribute on unpacked non-POD field on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com 2005-09-12 13:45 --- Created an attachment (id=9709) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9709action=view) output from compler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: ignoring packed attribute on unpacked non-POD field on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com 2005-09-12 13:46 --- Created an attachment (id=9710) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9710action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: ignoring packed attribute on unpacked non-POD field on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com
2005-09-12 13:46 ---
#include iostream
templatetypename D, typename W
struct GuidTemplate
{
char kk;
D TimeLow;
W TimeMid;
W TimeHiAndVer;
union
{
char ClkSeqAndNodeArray[8];
long long ClkSeqAndNodeQword;
struct
{
char ClkSeqHiAndVariant;
char ClkSeqLow;
char Node[6];
};
};
GuidTemplate() {}
} __attribute__ ((packed));
typedef GuidTemplatelong, short LeGuid;
struct PartitionEntry
{
LeGuid PartitionTypeGuid; // Unique ID that defines the purpose and type of
this Partition.
// A value of zero defines that this partition
// record is not being used.
LeGuid UniquePartitionGuid;// GUID that is unique for every partition
record. Every
// partition ever created will have a unique GUID.
This
// GUID must be assigned when the GUID Partition
Entry
// is created. The GUID Partition Entry is created
when
// ever the NumberOfPartitionEntries in the
// GUID Partition Table Header is increased to
include a
// larger range of addresses.
//le_qword StartingLba;// Starting LBA of the partition defined by this
record
///le_qword EndingLba; // Ending LBA of the partition defined by this
record
//le_qword Attributes; // All bit EFI Reserved
//le_word PartitionName[GPT_PARTITION_NAME_LENGTH]; // Human readable
Unicode string identification
} __attribute__ ((packed));
int main()
{
PartitionEntry entry;
std::cout sizeof structute LeGuid = sizeof(LeGuid) \n;
std::cout sizeof structute PartitionEntry = sizeof(PartitionEntry)
\n;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug middle-end/23290] Layout changed for structure with single complex field
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 13:50 --- Subject: Bug 23290 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 13:50:03 Modified files: gcc: ChangeLog stor-layout.c Log message: PR middle-end/23290 * stor-layout.c (compute_record_mode): For records with a single field, actually check the field's mode size against the type size. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9937r2=2.9938 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gccr1=1.241r2=1.242 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23290
[Bug target/23831] [4.1 Regression] ICE in immed_double_const with vectorized multipication
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 13:51 --- Confirmed, works correctly on powerpc-darwin with about the same IR. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Known to fail||4.1.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-09-12 13:51:38 date|| Summary|ICE in immed_double_const |[4.1 Regression] ICE in |with vectorized |immed_double_const with |multipication |vectorized multipication Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23831
[Bug tree-optimization/23818] [4.1 Regression] ICE in dominated_by_p, at dominance.c:827
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-09-12 14:20 --- Patch posted. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00719.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23818
[Bug fortran/23815] Add -byteswapio flag
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 14:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-12 14:29:20 date|| Summary|Add -byteswapio flag|Add -byteswapio flag http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug rtl-optimization/23812] swapping DImode halves produces poor x86 register allocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 14:31 --- Confirmed, basicially the same issue as PR 15792. -- What|Removed |Added BugsThisDependsOn||15792 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-12 14:31:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23812
[Bug middle-end/23290] [4.0 Regression] Layout changed for structure with single complex field
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 14:52 --- Confirmed, only a 4.0 regression now. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-12 14:52:40 date|| Summary|Layout changed for structure|[4.0 Regression] Layout |with single complex field |changed for structure with ||single complex field Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23290
[Bug c++/23823] Is this right?
--- Additional Comments From bangerth at dealii dot org 2005-09-12 14:54 --- (In reply to comment #9) Of course, if the target audience for gcc is the developers that work on it, then the present message is just fine... Well, it certainly isn't. We are just struggling with trying to find wordings that are understandable for the laypeople while still trying to be concise in notation, i.e. using the terminology of the standard. In addition, error messages need to be short. I, too, use argument and parameter interchangeably in colloquial speaking, but I believe that we should not do that in error messages. That said, I think Richard's suggestion in comment #7 goes in the right direction. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug rtl-optimization/23098] [4.1 Regression] store of 0.0 to float
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 15:12 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 15:21 --- Fixed at least on the mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug libfortran/21468] vectorizing libfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 15:23 --- PR 22480 refences a PR which currently blocks doing this. -- What|Removed |Added BugsThisDependsOn||22480 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
[Bug c++/23823] Is this right?
--- Additional Comments From gdr at integrable-solutions dot net 2005-09-12 15:39 --- Subject: Re: Is this right? bangerth at dealii dot org [EMAIL PROTECTED] writes: | That said, I think Richard's suggestion in comment #7 goes in the right | direction. Indeed. I would approve a patch implementating that suggestion. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 15:46 --- Subject: Bug 23237 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 15:46:35 Modified files: gcc: ChangeLog ipa-reference.c Log message: pr middle-end/23237 * ipa-reference.c (static_execute): Don't mark variables in named sections TREE_READONLY. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9940r2=2.9941 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ipa-reference.c.diff?cvsroot=gccr1=2.3r2=2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 15:50 --- Subject: Bug 23237 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 15:50:08 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr23237.c Log message: pr middle-end/23237 * gcc.c-torture/compile/pr23237.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6047r2=1.6048 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23237.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug tree-optimization/23834] New: Not removing a SSA_NAME which is not used
Take following code:
int g(void);
int h(void)
{
int i = g();
return 9;
}
int h1(void)
{
g();
return 9;
}
In h(), we could remove the assignment to i and this helps out a little in
compile time when expanding
to RTL. DCE could be doing this but does not. I thought about this issue when
I was working on my
quick and dirty DCE.
--
Summary: Not removing a SSA_NAME which is not used
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: enhancement
Priority: P2
Component: tree-optimization
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=23834
[Bug c++/23835] New: case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
We observe that on ia64, gcc -On -c test.ii (n = 1,2,3) is several times slower under gcc 4.1.0 than gcc 3.4.3: Compile time in seconds -O0 -O1-O2 -O3 3.4.3 5.659 9.515 13.811 14.779 4.1.0 8.417 44.652 56.176 60.204 This is typical of what we observe for compiles of long files. Hardware: IA-64 (Itanium 2), 1600 MHz, running Linux 2.6.12.2n. % gcc -v Reading specs from /util/bin/../lib/gcc/ia64-unknown-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/mnt/util/ia64 Thread model: posix gcc version 3.4.3 % gcc -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../configure --prefix=/wga1/gcc Thread model: posix gcc version 4.1.0 20050730 (experimental) -- Summary: case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaffe at broad dot mit dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 16:32 --- (In reply to comment #0) % gcc -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../configure --prefix=/wga1/gcc Thread model: posix gcc version 4.1.0 20050730 (experimental) You are compiling with checking enabled. Try to configure with --enable-checking=release and try again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From jaffe at broad dot mit dot edu 2005-09-12 16:33 --- Created an attachment (id=9711) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9711action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug ada/23836] New: Invalid code generated
The gnat 4.0 compiler generates invalid code for the following program. The output of the program is 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 which is of course not right... If line labelled 1 is removed and replaced by line labelled 2, the output is correct. The output is also correct if part 1 is replaced by part 2, while both parts are semanticaly identical.It must also be noted that the overlay is only declared and never used. The code is OK with gnat 3.4 Command passed by gnat to gcc: gcc-4.0 -c toto.adb Result of gcc -v: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6) ADA program: with Text_Io; use Text_Io; with Interfaces; use Interfaces; procedure Toto is type Intboard is new Unsigned_64; for Intboard'Size use 64; type Bit is new Integer range 0..1; for Bit'Size use 1; type Bitboard is array (0..63) of Bit; pragma Pack(Bitboard); for Bitboard'Size use 64; A_B : Bitboard; A_I : Intboard; for A_I'Address use A_B'Address;--label1 -- for A_B'Address use A_I'Address; --label2 begin --part 1 for I in 0 .. 7 loop for J in 0 .. 7 loop A_B(I*8+J) := 1; Put(Bit'Image(A_B(I*8+J))); end loop; end loop; --part 2 -- for I in 0 .. 63 loop -- A_B(I) := 1; -- Put(Bit'Image(A_B(I))); -- end loop; end Toto; -- Summary: Invalid code generated Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james at recherche dot enac dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23836
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 17:54 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug target/23552] FAIL: gfortran.dg/large_real_kind_1.f90
--- Additional Comments From sje at cup dot hp dot com 2005-09-12 18:31 --- This failure is due to the fact that isfinite() does not work for 'long double' types on HP-UX 11.00. isfinite() is used when writing floating point values in the Fortran IO library. -- What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-12 18:31:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23552
[Bug c++/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23437] [3.4/4.0/4.1 Regression] error: ... cannot appear in a constant-expression
--- Additional Comments From pannuri at cavs dot msstate dot edu
2005-09-12 18:39 ---
It seems this works:
#include math.h
#include stdio.h
static const double PI = M_PI;
static const double TWO_PI = (2.0*PI);
static const double HALF_PI = (M_PI_2);
static const double QUARTER_PI = (M_PI_4);
main (int argc, char** argv) {
int i = 0;
printf(%ld\n, i);
return 0;
}
But putting these inside of a class doesn't work:
class Foo {
Foo(){};
~Foo(){};
static const double PI = M_PI;
static const double TWO_PI = (2.0*PI);
static const double HALF_PI = (M_PI_2);
static const double QUARTER_PI = (M_PI_4);
};
-Madhulika
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23437
[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries
-- What|Removed |Added BugsThisDependsOn||22309 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
[Bug c++/23691] [4.0 Regression] `mpl_::bool_false::value' is not a valid template argument for type `bool' because it is a non-constant expression
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 19:01 --- Subject: Bug 23691 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 19:00:57 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: static16.C Log message: PR c++/23691 * g++.dg/template/static16.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6048r2=1.6049 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/static16.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug rtl-optimization/23837] New: [4.0, 4.1 regression] Wrong code with -fschedule-insns
[forwarded from http://bugs.debian.org/326026]
[EMAIL PROTECTED]:~% cat test.c
void abort(void);
unsigned long long f(unsigned long long x) {
return ((x 8) | (x 56)) ^ ((x 48) | (x 16)) ^ (x 1);
}
int main() {
volatile unsigned long long v = 0x1122334455667788ULL;
if (f(v) != 0xb3c46ef7196e4c91ULL)
abort();
return 0;
}
[EMAIL PROTECTED]:~% gcc-4.0 -O1 -fno-schedule-insns test.c ./a.out
[EMAIL PROTECTED]:~% gcc-4.0 -O1 -fschedule-insns test.c ./a.out
zsh: abort (core dumped) ./a.out
Reproduced with 4.0.2 20050821 on hppa-linux and with 4.1.0 20050705 on
i686-linux.
--
Summary: [4.0, 4.1 regression] Wrong code with -fschedule-insns
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:02 --- This should be solved with 22309. I'd like to consolidate the bug reports to 22309, and am closing this one. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:03 --- *** This bug has been marked as a duplicate of 22309 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:03 --- *** Bug 19265 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||l_heldt at poczta dot onet ||dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/23734] [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:04 --- Ok, ok, I'm on these two. -benjamin -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 19:05 --- Confirmed but works with 4.0.0 20050225. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-09-12 19:05:03 date|| Summary|[4.0, 4.1 regression] Wrong |[4.0/4.1 regression] Wrong |code with -fschedule-insns |code with -fschedule-insns Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:05 --- I believe this is yet another manifestation of 22309. -- What|Removed |Added BugsThisDependsOn||22309 AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
[Bug libstdc++/22612] linking error while compiling ddd with g++ 3.4.0 on solaris 9,
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:08 --- Waiting for feedback. Also, can you make sure that the toolchain you are using passes the regression tests (ie make check?) thanks, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
[Bug libstdc++/23278] SJLJ-exceptions broken
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:13 --- There are no platform details, no reproducing sources, and all this on a toolchain that is now mostly frozen. In addition, I also cannot tell why dwarf eh is not being used. So, the answer the question, does anybody use SJLJ exceptions on linux is: no, not really. Not unless the target is completely brain dead. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23278
[Bug libstdc++/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:18 --- Agree with Gaby. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Additional Comments From falk at debian dot org 2005-09-12 19:19 --- (In reply to comment #14) Why not reopen this to add a -Wundefined-behavior, so that at least bugs like that could be caught up front when using -Werror? There is already an unconditional warning, so what would be the point? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug libstdc++/23417] bits/stl_tree.h isn't -Weffc++ clean
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-12 19:20 --- Reproducer, compile with -Weffc++. #include list std::listint l; ...fixing -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23417
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complexT
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12
19:21 ---
(In reply to comment #5)
Agree with Gaby.
I disagree but what do I know.
It would be like doing:
int f(void)
{
int i;
i = (i0x) | 0x;
i = (i0x) | 0x;
return i;
}
There is no different in this example or the example which Falk gave really.
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
Component|libstdc++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
