Re: strict aliasing question
Dave Korn wrote: On 12 November 2006 04:16, Howard Chu wrote: Dave Korn wrote: f = (struct foo *)(void *)buf; That's good, but why is it safe? Passing through void* means gcc has to assume it could alias anything, IIUIC, as a result of the standard allowing implicit void*=T* conversions. Ah right, 6.5.16.1 Simple assignment, Constraints... one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; So actually f = (void *)buf; works without complaint. Thanks for pointing that out. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: strict aliasing question
Howard Chu [EMAIL PROTECTED] writes: As I recall, we chose int[] for alignment reasons, figuring we'd have no guarantees on the alignment of a char[]. Neither you have on int[]. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bootstrap failure on HEAD
I see this on linux but not on cygwin: make[3]: Leaving directory `/home/dk/gnu/obj' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/dk/gnu/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/dk/gnu/obj' make: *** [all] Error 2 [EMAIL PROTECTED] obj]$ ../gcc/config.guess i686-pc-linux-gnu [EMAIL PROTECTED] obj]$ uname -a Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] obj]$ Is it just me, or does anyone else get this? I objdump'd and diff'd the stage2 and stage3 versions of cfg.o and it seems to have developed a habit of inserting 'shrd'/'shld' opcodes: @@ -8895,8 +8896,10 @@ scale_bbs_frequencies_gcov_type: : 11 4c 24 34 %ecx,0x34(%esp,1) : 8b 5c 24 34 mov0x34(%esp,1),%ebx : 8b 4c 24 30 mov0x30(%esp,1),%ecx -: c1 e0 10shl$0x10,%eax : 8b 54 24 44 mov0x44(%esp,1),%edx +: 0f ac d9 01 shrd $0x1,%ebx,%ecx +: 0f a4 c2 10 shld $0x10,%eax,%edx +: c1 e0 10shl$0x10,%eax : d1 fb sar%ebx : 01 c8 %ecx,%eax : 11 da %ebx,%edx although disturbingly enough there's a missing 'lea' too: @@ -8968,29 +8971,29 @@ scale_bbs_frequencies_gcov_type: : 31 d2 xor%edx,%edx : 01 c8 %ecx,%eax : 11 da %ebx,%edx +: 0f ac d0 10 shrd $0x10,%edx,%eax : c1 fa 10sar$0x10,%edx : 83 fe f8cmp$0xfff8,%esi : 89 46 30mov%eax,0x30(%esi) : 89 56 34mov%edx,0x34(%esi) -: 0f 84 62 03 00 00 je scale_bbs_frequencies_gcov_type+0x4d4 +: 0f 84 66 03 00 00 je scale_bbs_frequencies_gcov_type+0x4e4 : 8b 76 08mov0x8(%esi),%esi : 85 f6 test %esi,%esi : 89 74 24 60 mov%esi,0x60(%esp,1) -: 0f 85 ce 03 00 00 jne scale_bbs_frequencies_gcov_type+0x54f +: 0f 85 d2 03 00 00 jne scale_bbs_frequencies_gcov_type+0x55f : 31 c9 xor%ecx,%ecx : 31 ed xor%ebp,%ebp : 31 d2 xor%edx,%edx : 31 c0 xor%eax,%eax -: 8d b4 26 00 00 00 00lea0x0(%esi,1),%esi : 39 c1 cmp%eax,%ecx -: 0f 84 76 03 00 00 je scale_bbs_frequencies_gcov_type+0x50e +: 0f 84 81 03 00 00 je scale_bbs_frequencies_gcov_type+0x51e cheers, DaveK -- Can't think of a witty .sigline today
Bila JPJ tak kata apa-apa....
Gempar hari ini berikut sebilangan besar pegawai JPJ tak mempedulikan apa yg berlaku sekarang, apabila pihak JPJ tidak menghiraukan org ramai memasang stiker di kenderaan berikutan pendapatan lumayan yang diperolehi hasil stiker yg ditampal anda dan cuba juga? cuma lengkap beberapa maklumat dan terima email pengesahan Terima Kasih Mendaftar di http:// simurl.com/wimmal http:// simurl.com/wimmal http:// simurl.com/wimmal http:// simurl.com/wimmal http:// simurl.com/wimmal Bila JPJ tak kata apa-apa
Re: bootstrap failure on HEAD
Dave Korn writes: Is it just me, or does anyone else get this? I objdump'd and diff'd the stage2 and stage3 versions of cfg.o and it seems to have developed a habit of inserting 'shrd'/'shld' opcodes: It looks to me like the stage3 version with the shrd/shld is correct and it's that stage2 version that's missing opcodes. In both versions the source and destination of the shift are a 64-bit pair of registers, but the stage2 version uses 32-bit shifts, while the stage3 version uses 64-bit shitfs. The code in the first chunk looks like it's the result of the expansion of the RDIV macro with the dividend being a gcov_type value and the divisor being 65536. It looks like gcov_type is 64-bits, so it should be using 64-bit arithmetic. although disturbingly enough there's a missing 'lea' too: It's a NOP. Probably inserted by the assembler because of an alignment directive. Ross Ridge
Re: bootstrap failure on HEAD
I see this on linux but not on cygwin: make[3]: Leaving directory `/home/dk/gnu/obj' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/dk/gnu/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/dk/gnu/obj' make: *** [all] Error 2 I also see this bootstrap failure on i386-redhat-linux systems - on the one system the gcc used to compile stage1 is: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) on the other system it is: gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47). On both systems, when I use gcc 4.1.1 to compile stage1 instead of the above - bootstrap passes smoothly. dorit [EMAIL PROTECTED] obj]$ ../gcc/config.guess i686-pc-linux-gnu [EMAIL PROTECTED] obj]$ uname -a Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002i686 i686 i386 GNU/Linux [EMAIL PROTECTED] obj]$ Is it just me, or does anyone else get this? I objdump'd and diff'd the stage2 and stage3 versions of cfg.o and it seems to have developed a habit of inserting 'shrd'/'shld' opcodes: @@ -8895,8 +8896,10 @@ scale_bbs_frequencies_gcov_type: : 11 4c 24 34 %ecx,0x34(%esp,1) : 8b 5c 24 34 mov0x34(%esp,1),%ebx : 8b 4c 24 30 mov0x30(%esp,1),%ecx -: c1 e0 10shl$0x10,%eax : 8b 54 24 44 mov0x44(%esp,1),%edx +: 0f ac d9 01 shrd $0x1,%ebx,%ecx +: 0f a4 c2 10 shld $0x10,%eax,%edx +: c1 e0 10shl$0x10,%eax : d1 fb sar%ebx : 01 c8 %ecx,%eax : 11 da %ebx,%edx although disturbingly enough there's a missing 'lea' too: @@ -8968,29 +8971,29 @@ scale_bbs_frequencies_gcov_type: : 31 d2 xor%edx,%edx : 01 c8 %ecx,%eax : 11 da %ebx,%edx +: 0f ac d0 10 shrd $0x10,%edx,%eax : c1 fa 10sar$0x10,%edx : 83 fe f8cmp$0xfff8,%esi : 89 46 30mov%eax,0x30(%esi) : 89 56 34mov%edx,0x34(%esi) -: 0f 84 62 03 00 00 je scale_bbs_frequencies_gcov_type+0x4d4 +: 0f 84 66 03 00 00 je scale_bbs_frequencies_gcov_type+0x4e4 : 8b 76 08mov0x8(%esi),%esi : 85 f6 test %esi,%esi : 89 74 24 60 mov%esi,0x60(%esp,1) -: 0f 85 ce 03 00 00 jne scale_bbs_frequencies_gcov_type+0x54f +: 0f 85 d2 03 00 00 jne scale_bbs_frequencies_gcov_type+0x55f : 31 c9 xor%ecx,%ecx : 31 ed xor%ebp,%ebp : 31 d2 xor%edx,%edx : 31 c0 xor%eax,%eax -: 8d b4 26 00 00 00 00lea0x0(%esi,1),%esi : 39 c1 cmp%eax,%ecx -: 0f 84 76 03 00 00 je scale_bbs_frequencies_gcov_type+0x50e +: 0f 84 81 03 00 00 je scale_bbs_frequencies_gcov_type+0x51e cheers, DaveK -- Can't think of a witty .sigline today
Re: bootstrap failure on HEAD
On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote: I see this on linux but not on cygwin: make[3]: Leaving directory `/home/dk/gnu/obj' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/dk/gnu/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/dk/gnu/obj' make: *** [all] Error 2 [EMAIL PROTECTED] obj]$ ../gcc/config.guess i686-pc-linux-gnu [EMAIL PROTECTED] obj]$ uname -a Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] obj]$ Gcc mainline may miscompile gcc when -O2 is used. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680 I have no problems on x86, x86-64 and ia64 with revision 118723 today after reverting revision 117986. Can you try http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574 H.J.
optimize option in macros or somevalue (-O2 or -O3)
Hi, Is there any way to specify in the code the optimization value like (-O2 or -O3) instead of on the command line. I want #include stdio.h ... ... return 0 } to be compiled with -O2 or -O3 or some better optimization than standard gcc flags like gcc a.c .I have only 1 file. The problem is i can't modify the makefile. The constraint is it get it optimized from the code using some technique like macro for (preprocessor ) or something. Can anyone help me on this. Regards Nik
Re: subreg transformation causes incorrect post_inc
[EMAIL PROTECTED] wrote: From: Mark Shinwell [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My port, based on (GCC) 4.2.0 20061002 (experimental), is producing incorrect code for the following test case: [snip] I've only had a very quick look at your code, but I have a feeling thatthis is an instance of the kind of slip-up with GO_IF_MODE_DEPENDENT_ADDRESSthat my patch at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00858.html is aimed at preventing. (This patch is currently only applied to addrmodesbranch.) Mark Hhmm. Is the intent of your patch simply to prevent the mistake of backends not defining GO_IF_MODE_DEPENDENT_ADDRESS properly? That's right. Presumably something else is wrong, then :-) Mark
Re: strict aliasing question
On Nov 11, 2006, at 7:56 PM, Howard Chu wrote: You probably can't, in the case of a shared library, but you probably could for a static library. I think I agree, though, a JIT can peer past a shared boundary as well. A non-JIT can as well, but it has to have some mechanism to unpeer across the boundary and notice updates to the other side of the boundary. I don't think we'll be peering across a shared boundary in the next 10 years, but, maybe one day. How will you distinguish these two cases, when all you see is foo.a on the command line? You don't, not for foo.a.
Re: Reducing the size of C++ executables - eliminating malloc
Michael Eager wrote:
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program int main() { return 0; }. GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http://sourceware.org/ml/newlib/2006/msg00181.html).
There are references to malloc in eh_alloc.c and
unwind-dw2-fde.c. It looks like these are being
included even when there are no exception handlers.
Any suggestions on how to eliminate the references
to these routines?
These aren't full implementation sketches, but, yes, we can do better.
Here are some ideas:
1. For the DWARF unwind stuff, have the linker work out how much space
is required and pre-allocate it. The space required is a statically
knowable property of the executable, modulo dynamic linking, and on the
cases where we care most (bare-metal) we don't have to worry about
dynamic linking. (If you can afford a dynamic linker, you can probably
afford malloc, and it's in a shared library.)
2. For the EH stuff, the maximum size of an exception is also statically
knowable, again assuming no dynamic linking. The maximum exception
nesting depth (i.e., the number of simultaneously active exceptions) is
not, though. So, here, what I think you want is a small, statically
allocated stack, at least as big as the biggest exception, out of which
you allocate exception objects. Happily, we already have this, in the
form of emergency_buffer -- although it uses a compile-time estimate
of the biggest object, rather than having the linker fill it in, as
would be ideal. But, in the no-malloc case, just fall back to the
emergency mode.
You could also declare malloc weak in that file, and just not call it
if the value is zero. That way, if malloc is around, you can use it --
but if it's not, you use the emergency buffer. Put the emergency_buffer
in a separate file (rather than in eh_alloc.cc), so that users can
provide their own implementation to control the size, overriding the one
in the library.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: C++: Implement code transformation in parser or tree
Sohail Somani wrote:
On Fri, 2006-11-10 at 19:46 -0800, Andrew Pinski wrote:
On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote:
Do you need new class types, or just an anonymous FUNCTION_DECL?
Hi Mark, thanks for your reply.
In general it would be a new class. If the lambda function looks like:
void myfunc()
{
int a;
...(int i1,int i2) extern (a) {a=i1+i2}...
}
That would be a new class with an int reference (initialized to a) and
operator()(int,int).
Does that clarify?
Can lambda functions like this escape myfunc? If not then using the
nested function mechanism that is already in GCC seems like a good
thing. In fact I think of lambda functions as nested functions.
Yes they can in fact. So the object can outlive the scope.
As I understand the lambda proposal, the lambda function may not refer
to things that have gone out of scope. It can use *references* that
have gone out of scope, but only if the referent is still in scope.
Since the way that something like:
int i;
void f() {
int a = i;
...() { return a; } ...
}
should be implemented is with a lambda-local copy of a (rather than a
pointer to a), this is OK.
So, I do think that nested functions would be a natural implementation
in GCC, since they already provide access to a containing function's
stack frame. You could also use the anonymous-class approach that you
suggested, but, as the lambda proposal mentions, using a nested function
may result in better code. I suspect that what you want is a class (to
meet the requirements on ret_type, etc.) whose operator() is marked as a
nested function for GCC, in the event -- and *only* in event -- that the
lambda function refers to variables with non-static storage duration.
Also, it appears to me that there is something missing from N1958: there
is no discussion about what happens when you apply typeid to a lambda
function, or otherwise use it in a context that requires type_info.
(Can you throw it as an exception, for example?) Can you capture its
type with typeof()? Can you declare a function with a paramter of type
pointer-to-lambda-function? Is this discussed, or am I missing something?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
RE: bootstrap failure on HEAD
On 12 November 2006 16:50, H. J. Lu wrote: On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 Gcc mainline may miscompile gcc when -O2 is used. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680 I have no problems on x86, x86-64 and ia64 with revision 118723 today after reverting revision 117986. Can you try http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574 Hi H.J., I updated to the revision you said, tried a clean bootstrap and verified the bug was still present, then applied your patch, and continued the bootstrap. I still get the same problem, so I have to conclude that Dorit is most likely correct to suggest the host compiler is at fault: I have been using 3.2 Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Since 3.x is dead, I'm not going to investigate, I'll just try using an intermediate 4.1 to get going. Thanks for the suggestion. cheers, DaveK -- Can't think of a witty .sigline today
Re: optimize option in macros or somevalue (-O2 or -O3)
Don't post to both lists, if you want to work on the compiler, gcc is fine, otherwise gcc-help. On Nov 12, 2006, at 9:29 AM, Niklaus wrote: Is there any way to specify in the code the optimization value like (-O2 or -O3) instead of on the command line. In Apple's branch, we've added support for #pragma to control these things, but in the mainline compiler, no. The problem is i can't modify the makefile. This is a rather poor reason to want to the feature. Use make CC='gcc -O2' instead, that doesn't modify the makefile and yet optimizes.
Re: gmp/mpfr and multilib
On Nov 11, 2006, at 11:19 AM, Jack Howarth wrote: Will any of the libraries in gcc now require gmp/mpfr such that both 32-bit and 64-bit versions of gmp/mpfr must be installed? If that is the case, will the multilib build look for both a lipo 32- bit/64-bit combined shared library in $prefix/lib as well as individual versions in lib and lib64 subdirectories? If you want to build darwin native and cross compilers and canadian cross compilers all at once, it is easiest to have built the libraries universal, other than that, no, they can be thin for the build system. The search path doesn't change between 32 and 64 bit compilers as I recall.
Re: build failure, GMP not available
On Mon, 30 Oct 2006, Kaveh R. GHAZI wrote: Do we have a GCC FAQ somewhere? Maybe we can add GMP/MPFR build problems and solutions there. You can add your experiences to that collection. http://gcc.gnu.org/faq.html, but I believe increasing the intelligence of configure and documenting all this in doc/install.texi probably is the better approach than adding something to this FAQ. Gerald
RE: gcc trunk
On Thu, 2 Nov 2006, Dave Korn wrote: From a user perspective, how about Current (4.1) Previous (4.0) Next (4.2) Active development (4.3) Let's be user-centric. Us developers can be expected to cope. Okay. ;-) Nobody else chimed in, so I went ahead and committed the patch below. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.583 diff -u -3 -p -r1.583 index.html --- index.html 6 Nov 2006 07:36:09 - 1.583 +++ index.html 12 Nov 2006 20:46:12 - @@ -106,21 +106,6 @@ interface for C, C++ and Fortran. dl class=status -dtstrongNext release series:/strong - GCC 4.2.0 (a href=gcc-4.2/changes.htmlchanges/a) -/dtdd - Status: a href=develop.html#stage3Stage 3/a; - a href=http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html;2006-10-17/a - (regression fixes and docs only). - br / - a - href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.2amp;target_milestone=4.0.4amp;target_milestone=4.1.2amp;target_milestone=4.2.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp; field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=Serious - regressions/a. - a - href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.2amp;target_milestone=4.0.4amp;target_milestone=4.1.2amp;target_milestone=4.2.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0- 0=All - regressions/a. -/dd - dtstrongCurrent release series:/strong a href=gcc-4.1/GCC 4.1.1/a /dtdd @@ -148,6 +133,21 @@ interface for C, C++ and Fortran. Regressions/a. /dd +dtstrongNext release series:/strong + GCC 4.2.0 (a href=gcc-4.2/changes.htmlchanges/a) +/dtdd + Status: a href=develop.html#stage3Stage 3/a; + a href=http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html;2006-10-17/a + (regression fixes and docs only). + br / + a + href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.2amp;target_milestone=4.0.4amp;target_milestone=4.1.2amp;target_milestone=4.2.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp; field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=Serious + regressions/a. + a +
Re: Reducing the size of C++ executables - eliminating malloc
Mark Mitchell wrote:
Michael Eager wrote:
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program int main() { return 0; }. GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http://sourceware.org/ml/newlib/2006/msg00181.html).
There are references to malloc in eh_alloc.c and
unwind-dw2-fde.c. It looks like these are being
included even when there are no exception handlers.
Any suggestions on how to eliminate the references
to these routines?
These aren't full implementation sketches, but, yes, we can do better.
Here are some ideas:
1. For the DWARF unwind stuff, have the linker work out how much space
is required and pre-allocate it. The space required is a statically
knowable property of the executable, modulo dynamic linking, and on the
cases where we care most (bare-metal) we don't have to worry about
dynamic linking. (If you can afford a dynamic linker, you can probably
afford malloc, and it's in a shared library.)
2. For the EH stuff, the maximum size of an exception is also statically
knowable, again assuming no dynamic linking. The maximum exception
nesting depth (i.e., the number of simultaneously active exceptions) is
not, though. So, here, what I think you want is a small, statically
allocated stack, at least as big as the biggest exception, out of which
you allocate exception objects. Happily, we already have this, in the
form of emergency_buffer -- although it uses a compile-time estimate
of the biggest object, rather than having the linker fill it in, as
would be ideal. But, in the no-malloc case, just fall back to the
emergency mode.
You could also declare malloc weak in that file, and just not call it
if the value is zero. That way, if malloc is around, you can use it --
but if it's not, you use the emergency buffer. Put the emergency_buffer
in a separate file (rather than in eh_alloc.cc), so that users can
provide their own implementation to control the size, overriding the one
in the library.
Preallocating space is a good thing, particularly if the size
can be computed at compile time. It's a little bit more awkward
if it has to be calculated at link time.
On the other hand, why should either DWARF unwind or the eh_*
files be included if C++ exception handling is not used?
The minimal executable has a reference to __gxx_personality_v0.
This is defined in eh_personality.o, which has a reference to
__cxa_allocate_exception in eh_alloc.o. So this seems to be the
thread which pulls in all the other pieces.
Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
flag, but it would seem better if this symbol were only generated
when catch/throw was used. This happens in cxx_init_decl_processing(),
which is called before it's known whether or not EH is really needed.
Any suggestions on how to move this test later?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
warn_unused_result attribute ignoring
If I understood correctly, newer glibcs have added warn_unused_result attribute to several functions when compiling with -D_FORTIFY_SOURCE=2. I think this is a good idea in general, except there are some cases where I really don't care if the call succeeds or not. Traditionally it's been possible to use (void)chdir(/blah); to disable such warnings in lint, but this doesn't work with gcc. How about adding support for it? Of course I could just as well do if (chdir(/blah) 0) ; but that's kind of ugly and not self-explanatory. signature.asc Description: This is a digitally signed message part
Re: warn_unused_result attribute ignoring
On Sun, 2006-11-12 at 23:03 +0200, Timo Sirainen wrote: If I understood correctly, newer glibcs have added warn_unused_result attribute to several functions when compiling with -D_FORTIFY_SOURCE=2. warn_unused_result means warn if the result is unused even with (void). This warning is doing what it is designed to do. -D_FORTIFY_SOURCE=2 means warn when you are ignoring return values and other stuff. If chdir fails you should handle that case and not just ignore it like you are doing. Thanks, Andrew Pinski
Re: Reducing the size of C++ executables - eliminating malloc
Michael Eager wrote: Preallocating space is a good thing, particularly if the size can be computed at compile time. It's a little bit more awkward if it has to be calculated at link time. It's a bit awkward, but it's also one of the clever tricks ARM's proprietary linker uses, and we should use it too! Generating __gxx_personality_v0 is suppressed with the -fno-exceptions flag, but it would seem better if this symbol were only generated when catch/throw was used. This happens in cxx_init_decl_processing(), which is called before it's known whether or not EH is really needed. I believe that you need the personality routine if you will be unwinding through a function, which is why -fno-exceptions is the test. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: expanding __attribute__((format,..))
On Fri, 10 Nov 2006, Nuno Lopes wrote: On Fri, 10 Nov 2006, Ian Lance Taylor wrote: I kind of liked this idea: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html but of course it was insane. I still think a higher level state machine as described in the followups is how things should be done. wouldn't that be killing a mosquito with a bomb? :) (unless of course we can find a simple description language) Format checking is complicated. Over 5% of all the 4 or so test assertions in a gcc testsuite run are from format checking testcases. Format checking is one of the most difficult parts of the compiler to get correct from an i18n perspective (i.e. having all complete sentences available for translation); everything else in the C front end apart from parse errors should be correct in that regard. Can I do anything to help? I mean, can you point me the files and what should I do in order to make this move forward? (the most I've made was a few little patches to make a customized cross-compiler to a mips robot, so I'm not very familiarized with the code...) c-format.[ch]. Understand the logic in there as a whole. Consider what aspects of information about format strings are embedded in the code and how you might improve the datastructures, one aspect at a time, to describe that aspect in data rather than code. For verifying there are no unintended changes in the compiler's behavior, compare the exact diagnostic texts in gcc.log from test runs before and after each change. OK, thanks for your tips. I'll take a look at it as soon as I have some free time (aka as soon as this university semester ends). Nuno
Re: Reducing the size of C++ executables - eliminating malloc
Mark Mitchell wrote: Generating __gxx_personality_v0 is suppressed with the -fno-exceptions flag, but it would seem better if this symbol were only generated when catch/throw was used. This happens in cxx_init_decl_processing(), which is called before it's known whether or not EH is really needed. I believe that you need the personality routine if you will be unwinding through a function, which is why -fno-exceptions is the test. You mean unwinding stack frames to handle a thrown exception? That's true, but shouldn't this only be included when there exceptions are used? One of the C++ percepts is that there is no overhead for features which are not used. Why should the personality routine be included in all C++ programs? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Reducing the size of C++ executables - eliminating malloc
Michael Eager wrote: Mark Mitchell wrote: Generating __gxx_personality_v0 is suppressed with the -fno-exceptions flag, but it would seem better if this symbol were only generated when catch/throw was used. This happens in cxx_init_decl_processing(), which is called before it's known whether or not EH is really needed. I believe that you need the personality routine if you will be unwinding through a function, which is why -fno-exceptions is the test. You mean unwinding stack frames to handle a thrown exception? That's true, but shouldn't this only be included when there exceptions are used? No, it must be included if exceptions are enabled, and there are any objects which might require cleanups, which, in most C++ programs, is equivalent to there are any objects with a destructor. One of the C++ percepts is that there is no overhead for features which are not used. That objective does not hold for space, especially in the presence of exceptions. Why should the personality routine be included in all C++ programs? Because all non-trivial, exceptions-enabled programs, may need to do stack unwinding. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Reducing the size of C++ executables - eliminating malloc
Mark Mitchell wrote: Michael Eager wrote: Why should the personality routine be included in all C++ programs? Because all non-trivial, exceptions-enabled programs, may need to do stack unwinding. It would seem that the place to require the personality routine would be in the routine which causes the stack unwinding, not in every C++ object file, whether needed or not. For embedded targets, there are many C++ programs which are non-trivial and which do not require exception handling. My thoughts: 1) Exception support should be included only when used. 2) The default for -exceptions should be target dependent. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Reducing the size of C++ executables - eliminating malloc
On Sunday 12 November 2006 22:46, Michael Eager wrote: Mark Mitchell wrote: Michael Eager wrote: Why should the personality routine be included in all C++ programs? Because all non-trivial, exceptions-enabled programs, may need to do stack unwinding. It would seem that the place to require the personality routine would be in the routine which causes the stack unwinding, not in every C++ object file, whether needed or not. The problem is that the places that knows we're using exceptions don't know how to do the stack unwinding, or what we're unwinding through. Only the code being unwound knows how to do the unwinding. The frame unwind information contains a function pointer that is called to interpret the rest of the frame data. eg. C, C++ and Java all have different exception table formats, and different personality routines to interpret those tables. The code that calls throw(), and the implementation of thow() don't know which of these routines are needed. The code being unwound through (ie. with frame data) needs to be able to say I need routine X if __Unwind_Raise is used anywhere in this program. I'm not aware of any way of doing this, other than trying it and starting again if you guessed wrong. Paul
Re: Reducing the size of C++ executables - eliminating malloc
Michael Eager wrote: Mark Mitchell wrote: Michael Eager wrote: Why should the personality routine be included in all C++ programs? Because all non-trivial, exceptions-enabled programs, may need to do stack unwinding. It would seem that the place to require the personality routine would be in the routine which causes the stack unwinding, not in every C++ object file, whether needed or not. But, the way the ABI works requires a reference from each unit which may cause unwinding. Even if you lose the personality routine, you will still have the exception tables, which themselves are a significant cost. If you don't want to pay for exceptions, you really have to compile with -fno-exceptions. In that case, certainly, we should be able to avoid pulling in the personality routine. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
libffi on Macintel?
Can anyone confirm that the libffi shared libraries are properly built in gcc 4.2 branch (or trunk) on i386-apple-darwin8? I have had a report that the most recent snapshot of gcc 4.2 doesn't build libffi on Macintel boxes. This is rather disturbing since I assumed that Sandro's patches were all properly checked into gcc trunk before gcc 4.2 branched. Unfortunately I don't have a Macintel machine to test this one and no one seems to be submitting testresults for i386-apple-darwin8 (which is rather bad form for a putative primary platform). Jack
Re: Reducing the size of C++ executables - eliminating malloc
Mark Mitchell wrote: But, the way the ABI works requires a reference from each unit which may cause unwinding. Even if you lose the personality routine, you will still have the exception tables, which themselves are a significant cost. If you don't want to pay for exceptions, you really have to compile with -fno-exceptions. In that case, certainly, we should be able to avoid pulling in the personality routine. I think that we are actually in agreement, for the most part. The routines which need unwinding should have a reference to the personality module. Routines which don't need unwinding shouldn't have a superfluous reference to it. There is a check in doing_eh() in except.c which checks that -fexceptions is set if any exception-specific functions are used. It seems that this would be the place to generate the reference to __gxx_personality_v0. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: C++: Implement code transformation in parser or tree
Yes they can in fact. So the object can outlive the scope.
As I understand the lambda proposal, the lambda function may not refer
to things that have gone out of scope. It can use *references* that
have gone out of scope, but only if the referent is still in scope.
Since the way that something like:
int i;
void f() {
int a = i;
...() { return a; } ...
}
should be implemented is with a lambda-local copy of a (rather than a
pointer to a), this is OK.
This is valid but has the following behaviour:
int i;
tr1::functionint() f()
{
int a = i;
return () - int {return a;};
}
void doit()
{
i = 1;
tr1::functionint() g(f());
assert(g()==1);
i = 2; // Change the global variable
assert(g()==1); // f() returned an object that has a copy of a
}
According to my reading of n1968, this is valid code that does not invoke
undefined behaviour. That is, the unnamed function has a copy of the stack
(only the relevant variables though) by default. So it is valid to use
stack variables in the newly created function. To reproduce the case you
suggest above, the definition of f() would be (something like):
tr1::functionint() f()
{
// explicitly keep a reference to i , keeping a reference to a local
// variable is UB and could be a diagnostic
return - int extern (i){ return i; };
}
So, I do think that nested functions would be a natural implementation
in GCC, since they already provide access to a containing function's
stack frame.
I think the compiler could be smart in certain cases and reduce a n1968
function to a nested function. This is the case when all variables
referenced in the anonymous function are listed in the extern(...) block
or in the parameter list *and* the new function is not returned to
callers. I don't think this can be done in general though. Even for n1958
functions, there is a way to keep a copy of the stack (and then return
this new function, with copies intact). Currently, I am looking at the
n1968 proposal. You referenced the n1958 proposal. I don't know which one
will eventually be accepted and don't particularly care either way, I just
want to learn gcc ;) In either case though, we have to handle the case
where the new object has copies of the data on the stack/global scope.
You could also use the anonymous-class approach that you
suggested, but, as the lambda proposal mentions, using a nested function
may result in better code. I suspect that what you want is a class (to
meet the requirements on ret_type, etc.) whose operator() is marked as a
nested function for GCC, in the event -- and *only* in event -- that the
lambda function refers to variables with non-static storage duration.
I think this can be an optimization, yes.
Also, it appears to me that there is something missing from N1958: there
is no discussion about what happens when you apply typeid to a lambda
function, or otherwise use it in a context that requires type_info.
(Can you throw it as an exception, for example?) Can you capture its
type with typeof()? Can you declare a function with a paramter of type
pointer-to-lambda-function? Is this discussed, or am I missing something?
I think it's typeid is undefined but it has a valid type_info object.
Consider a function f(int) that keeps something by value and another by
reference with same call signature. Two different types. For most
purposes, people would be using tr1::function. The only places it would
affect is generic code (i.e., templates). But if generic code uses
typeid... That misses the whole point, I think. Otherwise, I think you
could capture its type using typeof.
Catching it as an exception would be difficult unless you can use typeof.
I think a new intermediate tree type would be beneficial. Atleast one pass
is necessary after the object is constructed to enable the nested function
optimization.
Of course, all this is silly if nested functions carry around their
lexical scope and can be returned. But I dont know that they do.
Thanks for your reply,
Sohail
Re: C++: Implement code transformation in parser or tree
Of course, all this is silly if nested functions carry around their
lexical scope and can be returned. But I dont know that they do.
A simple test case that would not invoke UB with n1968 lambda functions:
#include stdio.h
typedef void (*fn_t)();
void doinvoke(fn_t f)
{
f();
}
fn_t getit(int j)
{
int i=j;
void myfn()
{
printf(Doit. I dare you: %d\n,i);
}
doinvoke(myfn);
return myfn;
// under n1968, we'd
// return ()-void{printf(Doit. I dare you: %d\n,i);};
}
int main()
{
fn_t five = getit(5);
fn_t six = getit(6);
fn_t seven = getit(7);
five(); six(); seven();
}
Expected output:
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7
Actual output:
Doit. I dare you: 5
Doit. I dare you: 6
Doit. I dare you: 7
Doit. I dare you: 7
Segmentation fault (core dumped)
Re: Reducing the size of C++ executables - eliminating malloc
On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote: The code being unwound through (ie. with frame data) needs to be able to say I need routine X if __Unwind_Raise is used anywhere in this program. I'm not aware of any way of doing this, other than trying it and starting again if you guessed wrong. Again, IIRC ARM's linker does something clever here. Of course the ABI in use there is somewhat different, but I suspect it could be adapted. On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote: But, the way the ABI works requires a reference from each unit which may cause unwinding. Even if you lose the personality routine, you will still have the exception tables, which themselves are a significant cost. If you don't want to pay for exceptions, you really have to compile with -fno-exceptions. In that case, certainly, we should be able to avoid pulling in the personality routine. If you try what Michael's been saying, you'll notice that trivial C++ files get the personality routine reference even if they don't have anything with a destructor which would need cleaning up. We ought to be able to emit (somewhat smaller) unwind information which doesn't reference the personality routine if it's going to have nothing to do, shouldn't we? -- Daniel Jacobowitz CodeSourcery
Re: Reducing the size of C++ executables - eliminating malloc
On Monday 13 November 2006 00:53, Daniel Jacobowitz wrote: On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote: The code being unwound through (ie. with frame data) needs to be able to say I need routine X if __Unwind_Raise is used anywhere in this program. I'm not aware of any way of doing this, other than trying it and starting again if you guessed wrong. Again, IIRC ARM's linker does something clever here. Of course the ABI in use there is somewhat different, but I suspect it could be adapted. Probably. I don't think the ABI differences are relevant here. On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote: But, the way the ABI works requires a reference from each unit which may cause unwinding. Even if you lose the personality routine, you will still have the exception tables, which themselves are a significant cost. If you don't want to pay for exceptions, you really have to compile with -fno-exceptions. In that case, certainly, we should be able to avoid pulling in the personality routine. If you try what Michael's been saying, you'll notice that trivial C++ files get the personality routine reference even if they don't have anything with a destructor which would need cleaning up. We ought to be able to emit (somewhat smaller) unwind information which doesn't reference the personality routine if it's going to have nothing to do, shouldn't we? Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a personality routine. Paul
Re: Reducing the size of C++ executables - eliminating malloc
Daniel Jacobowitz wrote:
If you try what Michael's been saying, you'll notice that trivial
C++ files get the personality routine reference even if they don't
have anything with a destructor which would need cleaning up. We ought
to be able to emit (somewhat smaller) unwind information which doesn't
reference the personality routine if it's going to have nothing to do,
shouldn't we?
Certainly, there are at least some such cases. I guess a function whose
only callees (if any) are no-throw functions, and which itself does not
use throw, does not need frame information.
But, for something like:
extern void f();
void g() {
f(); f();
}
we do need unwind information, even though g has nothing to do with
exceptions.
However, I think you and Michael are right: we don't need to reference
the personality routine here. Unless the entire program doesn't
contain anything that needs cleaning up, we'll still need it in the
final executable, but omitting it would make our object files smaller,
and unwinding a little faster, since we don't call personality routines
that aren't there.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: C++: Implement code transformation in parser or tree
Mark Mitchell [EMAIL PROTECTED] writes: [...] | Also, it appears to me that there is something missing from N1958: there | is no discussion about what happens when you apply typeid to a lambda | function, or otherwise use it in a context that requires type_info. There still are some discussions going on (it is not alsways feasable to reflect all the discussions), especially with respect to callback, default policy and the like. | (Can you throw it as an exception, for example?) Can you capture its | type with typeof()? lambdas are supposed to be usable with algorithms implemented as function templates, so I suspect they must be combinable with typeof. | Can you declare a function with a paramter of type | pointer-to-lambda-function? Is this discussed, or am I missing something? There is the discussion on callbacks. -- Gaby
Re: Reducing the size of C++ executables - eliminating malloc
On Mon, Nov 13, 2006 at 01:03:10AM +, Paul Brook wrote: C++ files get the personality routine reference even if they don't have anything with a destructor which would need cleaning up. We ought to be able to emit (somewhat smaller) unwind information which doesn't reference the personality routine if it's going to have nothing to do, shouldn't we? Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a personality routine. Right - which is why it was such a headache for us, isn't amenable to _Unwind_Backtrace / _Unwind_ForcedUnwind, et cetera. For .eh_frame, though, the personality routine is only necessary to run cleanups and check exception specs. -- Daniel Jacobowitz CodeSourcery
Re: Reducing the size of C++ executables - eliminating malloc
On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote: Daniel Jacobowitz wrote: If you try what Michael's been saying, you'll notice that trivial C++ files get the personality routine reference even if they don't have anything with a destructor which would need cleaning up. We ought to be able to emit (somewhat smaller) unwind information which doesn't reference the personality routine if it's going to have nothing to do, shouldn't we? Certainly, there are at least some such cases. I guess a function whose only callees (if any) are no-throw functions, and which itself does not use throw, does not need frame information. You've talked right past me, since I wasn't saying that... However, I think you and Michael are right: we don't need to reference the personality routine here. ... but this. Unless the entire program doesn't contain anything that needs cleaning up, we'll still need it in the final executable, Right. So if you use local variables with destructors, even though you don't use exceptions, you'll get the personality routine. The linker could straighten that out if we taught it to, though. -- Daniel Jacobowitz CodeSourcery
Re: C++: Implement code transformation in parser or tree
There still are some discussions going on (it is not alsways feasable to reflect all the discussions), especially with respect to callback, default policy and the like. [...] There is the discussion on callbacks. Are these discussions public? Is there a way to get archives? Thanks, Sohail
Re: C++: Implement code transformation in parser or tree
[EMAIL PROTECTED] writes: | There still are some discussions going on (it is not alsways feasable | to reflect all the discussions), especially with respect to callback, | default policy and the like. | | [...] | | There is the discussion on callbacks. | | Are these discussions public? Most of them happened at the last C++ committee meetings in Berlin, Germany and Portland, Oregon). There must be some record on the EWG wiki, but I don't think they are publically available. Some happen face-to-face over lunch or beer. -- Gaby
Would this interest anyone?
I am no longer subscribed to this list so please be sure to include my email address in any replies. I have been working on a set of class templates. Currently my example is rather large and cumbersome. I get the same results using g++ 4.0.1 on the Mac and g++ 4.0.2 on AIX. The templates are doing template expressions. There are two points that may or may not be of interest. 1) I put the typical NoCopy as a base class to hide the copy and copy- assignment methods. When I do that, one class no longer compiles. If I add a copy constructor, the class compiles but by the time the final output is done, it has been optimized away. This is without using any -O flags. I understand that all this is normal and o.k. but it made it hard for me to figure out what, if anything, I could do to change my code to prevent the need of the copy. I am still trying to figure out an approach to figure out where and why the extra copy is needed. (Note, that this will be a copy of a temporary.) 2) The class templaltes, as mentioned, are implementing what the books call template expressions. As an expression is parsed, a tree of C++ classes that replicates the parse tree is produced. Then the tree is evaluated and frequently compiles down to just constants which are folded into very efficient code. One of these expressions my look like this: p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; (which assigns the r value to a particular field of bits in a particular hardware register in memory mapped I/O). If I put these back to back like this: p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; the code produced is fantastic -- optimum code. Everything is inlined. Just wonderful code! (And I can alter the value of the [2] and other things and its all very very nice code.) If I break up the basic block by calling out like this: p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; nothing(1); p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; nothing(1); p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; nothing(1); p-*gr.portSlotStatusArray[2]-*pss.allSlotStatus = 0x12345678; nothing(1); (nothing is a function in an external file that does nothing) The compiler produces code that creates part (but not all) of the expression tree on the stack but never references it any place that I can see. The other odd thing is that these trees are in separate places in memory (so, in the case above, four separate copies of these trees will be created in four unique locations). So the space consumed by the temporary trees is not reclaimed (until the function returns). My question is if this is of interest to any of the developers. If it is, I will package up a nice test program and submit it via bugzilla. Perry Smith Ease Software, Inc. [EMAIL PROTECTED] http://www.easesoftware.com Low cost SATA Products for IBMs p5, pSeries, and RS/6000 AIX systems
GCC 4.1.2 Status Report (2006-11-12)
I realize that it's been a long time since a GCC 4.1.x release. I'd like to put together a GCC 4.1.2 release in the relatively near future. (Then, there may or may not be a GCC 4.1.3 release at the same time as 4.2.0, depending on where it seems like we are at that point.) Since, in theory, the only changes on the 4.1 release branch were to fix regressions, GCC 4.1.2 should be ready for release today, under the primary condition that it be no worse than 4.1.1. But, I recognize that while theory and practice are, in theory, the same, they are, in practice, different. I also see that there are some 30 P1s open against 4.1.2. Many of these also apply to 4.2.0, which means that fixing them helps both releases. So, I'd appreciate people working to knock down those PRs, in particular. I would also like to know which PRs are regressions from 4.1.0 or 4.1.1. Please update the list here: http://gcc.gnu.org/wiki/GCC_4.1.2_Status as you encounter such PRs. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Abt long long support
First thanks very much for your thoughts If those two instructions appear for the first time in the .greg dump file, then they have been created by reload. Yes they appear for the first time in .greg dump file. 1. What could be the reason for this behavior? I'm really shooting in the dark here, but my guess is that you have a define_expand for movdi that is not reload safe. You can do this operation correctly, you just have to reverse the instructions: load a5 from (a4 + 4) before you load a4 from (a4). See, e.g., mips_split_64bit_move in mips.c and note the use of reg_overlap_mentioned_p. I have already mentioned earlier in this conversation that adddi3 and subdi3 are the only DI mode patterns in the .md file. Then Rask pointed out that middile end will synthesize other patterns for DI mode looking at similar SI mode patters in the backend. As this is the case am i to assume that the synthesized movdi pattern is not safe for reload? Should i tweak the movsi pattern to to correct this issue or should i write a explicit movdi pattern ? With this in mind how come this worked fine in gcc 3.4.6 port of the target. Has the behavior of reload changed very much in gcc 4.1.1? Regards, Shafi
RE: Abt long long support
On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote: On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote: No, surely you don't want to do that! You really need a movdi pattern - even more so if there are no natural DImode-sized registers, as gcse can get terribly confused by bad reg_equal notes if you don't. See e.g.: http://gcc.gnu.org/ml/gcc/2003-04/msg01397.html http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html PR number? None that I could find. Most of the backends in mainline already have movdi patterns, this is the sort of problem you only run into when you're developing a custom backend. The only backends that don't define movdi (or indeed any DImode instructions) are avr c4x dsp16xx h8300 mn10200 stormy16 I don't know if it might be possible to demonstrate the problem on one of those platforms, I haven't tried. cheers, DaveK -- Can't think of a witty .sigline today
RE: How to create both -option-name-* and -option-name=* options?
On 11 November 2006 00:14, Brooks Moses wrote: Dave Korn wrote: On 10 November 2006 21:18, Brooks Moses wrote: I think that for this one case we should just say that you have to supply both forms -ffixed-line-length-none and -ffixed-line-length=none. Which I would be glad to do, except that as far as I can tell, it's not possible to actually do that. The same problem arises there as arises when it doesn't have none on the end and Joined in the specification. Oh of couse. Hey, isn't this where I came in? What you have here is really a joined option that has an argument that can be either a text field or an integer, and to save the trouble of parsing the field properly you're playing a trick on the options parser by specifying something that looks to the options machinery like a longer option with a common prefix, but looks to the human viewer like the same option with a text rather than integer parameter joined. Right, agreed. Though it's not so much to save the trouble as to be able to leverage all the useful things the option parser does to verify numeric fields. All the more reason to give the option parser even more useful things that it does that can be leveraged. And, given that adding support for both string and numeric values looks fairly easy (much more so than I would have guessed), that's probably the better way to go. A UIntegerOrString property would be incompatible with the Var property, since it would need two variables for storing the result, but I think this is not a notable loss since the combination of Var and UInteger is already rare -- the only flag that uses them both is -fabi-version. Or, given that the only thing that appears to use this at the moment is this old g77-style fixed-line-length Fortran option that we're only supporting for legacy purposes, I suppose we could just go for the cop-out of supporting the -none version and not the =none version, and only document it as accepting =0. Your choice; there's only a limited need to support ancient compile flags. Actually, perhaps you should fix this simply, by using a specs to rewrite the =none version into the -none version. Is there not a Fortran equivalent of CC1_SPEC/CC1PLUS_SPEC/... ? cheers, DaveK -- Can't think of a witty .sigline today
Re: Reducing the size of C++ executables - eliminating malloc
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program int main() { return 0; }. GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http://sourceware.org/ml/newlib/2006/msg00181.html).
We've seen this on cell spu as well. And with only 256K total memory it was a really big
deal for us. Our minimal program dropped from 10566 bytes to 2822 bytes (text + data +
bss) with the attached completely unacceptable for merging patch. We were thinking that
our platform has no need for more than 32 atexit handlers, and the proper solution is to
make the code removed in the attached patch simply #ifdefed away for platforms like ours
that are happy with 32 atexit handlers and are short on space. This seems to be the
approach in the patch you linked to.
-Joel
Index: newlib-1.14.0/newlib/libc/stdlib/__atexit.c
===
--- newlib-1.14.0.orig/newlib/libc/stdlib/__atexit.c
+++ newlib-1.14.0/newlib/libc/stdlib/__atexit.c
@@ -9,6 +9,7 @@
#include atexit.h
+
/*
* Register a function to be performed at exit or on shared library unload.
*/
@@ -24,6 +25,10 @@ _DEFUN (__register_exitproc,
struct _on_exit_args * args;
register struct _atexit *p;
+#ifdef _REENT_SMALL
+ static struct _on_exit_args myargs;
+#endif
+
#ifndef __SINGLE_THREAD__
__LOCK_INIT(static, lock);
@@ -35,21 +40,10 @@ _DEFUN (__register_exitproc,
_GLOBAL_REENT-_atexit = p = _GLOBAL_REENT-_atexit0;
if (p-_ind = _ATEXIT_SIZE)
{
- p = (struct _atexit *) malloc (sizeof *p);
- if (p == NULL)
- {
#ifndef __SINGLE_THREAD__
__lock_release(lock);
#endif
return -1;
- }
- p-_ind = 0;
- p-_next = _GLOBAL_REENT-_atexit;
- _GLOBAL_REENT-_atexit = p;
-#ifndef _REENT_SMALL
- p-_on_exit_args._fntypes = 0;
- p-_on_exit_args._is_cxa = 0;
-#endif
}
if (type != __et_atexit)
@@ -58,7 +52,8 @@ _DEFUN (__register_exitproc,
args = p-_on_exit_args_ptr;
if (args == NULL)
{
- args = malloc (sizeof * p-_on_exit_args_ptr);
+/* args = malloc (sizeof * p-_on_exit_args_ptr); */
+ args = myargs;
if (args == NULL)
{
#ifndef __SINGLE_THREAD__
Index: newlib-1.14.0/newlib/libc/stdlib/__call_atexit.c
===
--- newlib-1.14.0.orig/newlib/libc/stdlib/__call_atexit.c
+++ newlib-1.14.0/newlib/libc/stdlib/__call_atexit.c
@@ -68,10 +68,10 @@ _DEFUN (__call_exitprocs, (code, d),
/* Remove empty block from the list. */
*lastp = p-_next;
#ifdef _REENT_SMALL
- if (args)
- free (args);
+/* if (args) */
+/* free (args); */
#endif
- free (p);
+/* free (p); */
p = *lastp;
}
else
GCC Garbage Collection
Hi All,
I think i am having trouble with the garbage collector deleting the
memory for tree nodes that i am still using.
In my code i gather all sorts of information from FUNCTION_DECL
nodes as they pass through the gimplify_function_tree() function. I
gather info about types and functions and store that information in my
own data sturctures. Alongside this data i also store the original tree
node for the FUNCTION_DECL or type and later perform some post
processing using this node to gather additional information before
saving this data to a file.
I think that the garbage collector is cleaning up some of the nodes that
I have stored in my structures.
How can i determine if it is deleting the memory for this node?
I have read the GCC Internals manual on garbage collection, and am not
sure how I should use it in my situation. I have a dynamic array of my
own structs like below:
struct TypeInfoStruct
{
tree node;
my data
};
typedef TypeInfoStruct TypeInfo;
and i have an array of these declared in a .c file:
static TypeInfo** registered_types = NULL;
... initialise registered types array someplace in my code
I manage the memory for the registered types array and the TypeInfo
structure instances and can not give this to the garbage collector to
do. However the node element in the structure seems to become invalid.
To declare the node as being a root for garbage collection and thus
should not be freed should i declare my structure like:
struct TypeInfoStruct
{
GTY(()) tree node;
my data
};
I dont think this will work from what I have read it seems the garbage
collection only seems to work for single globals. How can i achieve this?
Thanks,
Brendon.
Re: C++: Implement code transformation in parser or tree
Quoting Gabriel Dos Reis [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: | There is the discussion on callbacks. | | Are these discussions public? Most of them happened at the last C++ committee meetings in Berlin, Germany and Portland, Oregon). There must be some record on the EWG wiki, but I don't think they are publically available. Some happen face-to-face over lunch or beer. I notice that your name is on the n1968 paper. Do you know which of the proposals is likely to make it? I'd suspect the n1968 one. I personally prefer the syntax of n1958(?) but that requires a significant amount of lookahead I think. Thanks!
Re: GCC Garbage Collection
Le Mon, Nov 13, 2006 at 06:47:40AM +, Brendon Costa écrivait/wrote: Hi All, I think i am having trouble with the garbage collector deleting the memory for tree nodes that i am still using. The wiki page http://gcc.gnu.org/wiki/Memory_management might help you I had a quick glance at your mail, so I may be wrong, but I am not sure that you configured correctly the build system so that thet GTY(()) macros get processed correctly. Sadly, the gengtype generator does not recieve the list of files to process thru the command line, but only in internal data. Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France
[Bug target/25500] [4.0/4.1/4.2/4.3 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-11-12 08:07 --- I should be posting a patch for this next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug rtl-optimization/29797] [4.1/4.2/4.3 Regression] Miscompiles bit test / set in OpenOffice
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-11-12 08:10 --- (In reply to comment #16) (In reply to comment #15) The patch fails bootstrap in stage2 for ppc (only). This bootstraps just fine for me on the mainline with powerpc-darwin. And there were no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-12 08:20 --- I am going to try to fix this, it blocks my other work on getting altivec builtins marked as const/pure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-12 08:20:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-12 08:35 ---
The only thing left from __task_rq_lock is a label.
If we look at that inlined function, we see:
static inline __attribute__((always_inline)) struct rq *__task_rq_lock(struct
task_struct *p)
{
struct rq *rq;
repeat_lock_task:
rq = ((*((void)((task_cpu(p))), per_cpu__runqueues)));
do { do { } while (0); (void)0; (void)(rq-lock); } while (0);
if (__builtin_expect(!!(rq != ((*((void)((task_cpu(p))),
per_cpu__runqueues, 0)) {
do { do { } while (0); (void)0; (void)(rq-lock); } while (0);
goto repeat_lock_task;
}
return rq;
}
the if is never true as rq is always equal to per_cpu__runqueues. The calls to
task_cpu were inlined and we constant proped the value of rq the first of the
way through the function which we inlined this to.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
[Bug inline-asm/29808] New: [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
The following code (extracted from the Linux kernel) fails to compile with
optimization enabled:
static void load_fs(unsigned short sel)
{
asm(mov %0, %%fs : : g(sel));
}
int main(int argc, char **argv)
{
load_fs(0);
}
[EMAIL PROTECTED] arklinux]$ gcc test.c
[EMAIL PROTECTED] arklinux]$ gcc -O1 test.c
/tmp/ccSpA5Rm.s: Assembler messages:
/tmp/ccSpA5Rm.s:13: Error: suffix or operands invalid for `mov'
gcc is 4.2 SVN revision 118519 (20061106).
--
Summary: [4.2 Regression] Error: suffix or operands invalid for
`mov' when optimization is enabled
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug c++/29809] New: Segmentation fault with 4.1.1 and 4.1-20061110
I get a segmentation fault with both stock gcc 4.1.1 and the 20061110 4.1.2 snapshot, when trying to build avifile-0.7.45. The error message is: if i386-pc-linux-g++ -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/lib/qt3/include -DQT_THREAD_SUPPORT -I/usr/X11R6/include -I../../libavqt -DI18N_PATH=\/usr/share/avifile-0.7/i18\ -Wall -Wno-unused -I../../include -O3 -march=i386 -fno-strength-reduce -save-temps -MT timertable.o -MD -MP -MF .deps/timertable.Tpo -c -o timertable.o timertable.cpp; \ then mv -f .deps/timertable.Tpo .deps/timertable.Po; else rm -f .deps/timertable.Tpo; exit 1; fi timertable.cpp: In member function 'void TimerTableItem::setTable(int, QDateTime, QTime, QString, QString, int, int, QString)': timertable.cpp:1371: 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. make[1]: *** [timertable.o] Error 1 make[1]: Leaving directory `/home/users/chris/tmp/avifile-0.7-0.7.45/samples/qtvidcap' make: *** [all-recursive] Error 1 The info about gcc is as follows: Using built-in specs. Target: i386-pc-linux Configured with: ../configure --prefix=/usr --infodir=/usr/info --mandir=/usr/man --enable-shared --disable-static --with-system-zlib --enable-threads=posix --enable-haifa --enable-languages=c,c++,java --enable-long-long --enable-namespaces --enable-multilib --with-gnu-as --with-gnu-ld --with-system-zlib --without-x --disable-werror --disable-checking --enable-__cxa_atexit --disable-nls --without-included-gettext i386-pc-linux Thread model: posix gcc version 4.1.2 20061110 (prerelease) The preprocessed source is 177Kb, even when bzip2ed. so I'll add it as an attachment. -- Summary: Segmentation fault with 4.1.1 and 4.1-20061110 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris_clayton at f1internet dot com GCC build triplet: i386-pc-linux GCC host triplet: i386-pc-linux GCC target triplet: i386-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug c++/29809] Segmentation fault with 4.1.1 and 4.1-20061110
--- Comment #1 from chris_clayton at f1internet dot com 2006-11-12 09:35 --- Created an attachment (id=12596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12596action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #19 from irar at il dot ibm dot com 2006-11-12 09:52 --- Janis, Thanks a lot! The range of the revisions is 110758 - 111615 (110758 passes bootstrap with vectorization with the patch, 111615 fails with the error in comment #3). I had to modify the patch and split it into two patches in order to make it possible to apply the patch automatically (without rejections). I am attaching the two parts. Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #20 from irar at il dot ibm dot com 2006-11-12 09:55 --- Created an attachment (id=12597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12597action=view) The first part of the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #21 from irar at il dot ibm dot com 2006-11-12 09:56 --- Created an attachment (id=12598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12598action=view) The second part of the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results
--- Comment #6 from bonzini at gnu dot org 2006-11-12 11:00 --- mine, but please can you give me the correct output? i don't see the regressions (comparing to a 4.1.2 compiler). -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-11 11:46:11 |2006-11-12 11:00:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
[Bug c++/29518] [4.0/4.1/4.2/4.3 Regression] rejects valid template argument, enums vs templates
--- Comment #12 from news at derived-software dot ltd dot uk 2006-11-12
11:04 ---
From Aleksey Gurtovoy (co-author Boost.MPL):
[wrt to this bug]
Actually, no, enums in the bug's subject and reduced test case are a
red herring. For example, this still fails for me on 4.1.1:
template int C int assertion_failed(int);
template class struct N
{
static int const value = 1;
static int const t = sizeof( assertion_failedvalue(0) );
};
int main()
{
Nint n;
return n.t;
}
As a matter of fact, my current workaround for this issue involves
_introducing_ an auxiliary enum for the values that are used in
function templates' non-type arguments, e.g.:
template int C int assertion_failed(int);
template class struct N
{
static int const value = 1;
enum { gcc_workaround = value };
static int const t = sizeof( assertion_failedgcc_workaround(0) ); // it
compiles, yay!
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #1 from segher at kernel dot crashing dot org 2006-11-12 11:10 --- Not a bug in GCC but in your code; g says immediate values are allowed, while this asm insn only takes registers (or 16-bit memory). -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results
--- Comment #7 from jpr at csc dot fi 2006-11-12 13:24 --- Subject: Re: [4.3 Regression] -O2 gives wrong results In reply to comment #6) mine, but please can you give me the correct output? i don't see the regressions (comparing to a 4.1.2 compiler). In the original testcase xvec should contain xvec[0]=1, xvec[1]=4 after the loop and it should only take 2 iterations to get there. Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-12 13:26 --- invalid -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug c++/29809] Segmentation fault with 4.1.1 and 4.1-20061110
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-12 13:37 --- With g++ 4.1.1-13 (g++ (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) I see timertable.cpp: In member function void TimerTableItem::setTable(int, QDateTime, QTime, QString, QString, int, int, QString): timertable.cpp:1371: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6336 with a checking enabled build of the 4.1 branch head I get timertable.cpp: In member function void TimerTableItem::setTable(int, QDateTime, QTime, QString, QString, int, int, QString): timertable.cpp:222: error: address taken, but ADDRESSABLE bit not set D.76377 timertable.cpp:222: error: address taken, but ADDRESSABLE bit not set D.76377 timertable.cpp:222: internal compiler error: verify_stmts failed Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #3 from bero at arklinux dot org 2006-11-12 13:40 --- If the code is invalid, the fact that it compiles with -O0 is probably a bug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #4 from segher at kernel dot crashing dot org 2006-11-12 14:01 --- If the code is invalid, the fact that it compiles with -O0 is probably a bug... No, GCC cannot in general detect whether your asm code is buggy. The assembler however can detect many asm bugs, as it did in this case. The reason it worked with -O0 is that with -O0 you get different generated code (namely, very inefficient code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug c++/29809] Segmentation fault with 4.1.1 and 4.1-20061110
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-12 14:18 ---
Confirmed. Reduced testcase that fails with -O -finline-functions:
class QDate { };
class QTime {
public:
bool operator( const QTime d ) const { return ds d.ds; }
unsigned ds;
};
class QDateTime {
public:
QDateTime( const QDate , const QTime );
QDate date() const { return d; }
QTime time() const { return t; }
QDateTime addDays( int days ) const;
QDate d;
QTime t;
};
class TimerTable;
class TimerTableItem {
void setTable(QDateTime start,QTime stop);
QDateTime start_time;
QTime stop_time;
QDateTime stop_datetime;
TimerTable *timer_window;
};
class TimerTable
{
public:
QDateTime calc_stopDateTime(QDateTime start_datetime,QTime stop_time);
};
void TimerTableItem::setTable(QDateTime start,QTime stop)
{
stop_datetime=timer_window-calc_stopDateTime(start_time,stop_time);
}
QDateTime TimerTable::calc_stopDateTime(QDateTime start_datetime,QTime
stop_time)
{
QTime start_time=start_datetime.time();
QDate start_date=start_datetime.date();
QDateTime stop_datetime(start_date,stop_time);
if(start_time stop_time )
stop_datetime=stop_datetime.addDays(1);
return stop_datetime;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.1.2
Last reconfirmed|-00-00 00:00:00 |2006-11-12 14:18:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug c++/29809] [4.1 Regression] Segmentation fault with 4.1.1 and 4.1-20061110
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1 RegressionSegmentation |[4.1 Regression] |fault with 4.1.1 and 4.1- |Segmentation fault with |20061110|4.1.1 and 4.1-20061110 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug c++/29809] [4.1 Regression] Segmentation fault with 4.1.1 and 4.1-20061110
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-12 14:46 ---
TREE_ADDRESSABLE is missing on D.1854 in
# start_dateD.1966_53 = V_MAY_DEF start_dateD.1966_31;
# SFT.44D.1986_54 = V_MAY_DEF SFT.44D.1986_12;
# SFT.45D.1987_55 = V_MAY_DEF SFT.45D.1987_13;
# SFT.48D.1990_56 = V_MAY_DEF SFT.48D.1990_17;
# SFT.50D.1992_57 = V_MAY_DEF SFT.50D.1992_24;
# SFT.55D.1997_58 = V_MAY_DEF SFT.55D.1997_41;
# SFT.56D.1998_59 = V_MAY_DEF SFT.56D.1998_40;
__comp_ctor (D.1854, start_dateD.1966, stop_timeD.1963)
right after running the first alias pass. This is from the inliner
replacing
__comp_ctor (retval, start_date, stop_time);
retval with D.1854 here.
It looks we simply forget to mark the decl addressable during inline
substitution here:
/* Variable substitution need not be simple. In particular, the
INDIRECT_REF substitution above. Make sure that TREE_CONSTANT
and friends are up-to-date. */
else if (TREE_CODE (*tp) == ADDR_EXPR)
{
walk_tree (TREE_OPERAND (*tp, 0), copy_body_r, id, NULL);
/* Handle the case where we substituted an INDIRECT_REF
into the operand of the ADDR_EXPR. */
if (TREE_CODE (TREE_OPERAND (*tp, 0)) == INDIRECT_REF)
*tp = TREE_OPERAND (TREE_OPERAND (*tp, 0), 0);
else
recompute_tree_invarant_for_addr_expr (*tp);
*walk_subtrees = 0;
}
or it should have been marked addressable earlier. That we don't hit
this more often and that trunk doesn't have the problem hints at that
the following is not the right fix?
Index: tree-inline.c
===
*** tree-inline.c (revision 118723)
--- tree-inline.c (working copy)
*** copy_body_r (tree *tp, int *walk_subtree
*** 714,720
if (TREE_CODE (TREE_OPERAND (*tp, 0)) == INDIRECT_REF)
*tp = TREE_OPERAND (TREE_OPERAND (*tp, 0), 0);
else
! recompute_tree_invarant_for_addr_expr (*tp);
*walk_subtrees = 0;
}
}
--- 714,724
if (TREE_CODE (TREE_OPERAND (*tp, 0)) == INDIRECT_REF)
*tp = TREE_OPERAND (TREE_OPERAND (*tp, 0), 0);
else
! {
! recompute_tree_invarant_for_addr_expr (*tp);
! if (DECL_P (TREE_OPERAND (*tp, 0)))
! TREE_ADDRESSABLE (TREE_OPERAND (*tp, 0)) = 1;
! }
*walk_subtrees = 0;
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug c++/15795] No way to teach operator new anything about alignment requirements
--- Comment #38 from timday at bottlenose dot demon dot co dot uk 2006-11-12 15:33 --- Gah: just spent several hours trying to figure out why my malloced __v4sf weren't 16 byte aligned before I stumbled on this thread. Would be nice if the info gcc Using vector instructions through built-in functions section contained a big warning about the issue. -- timday at bottlenose dot demon dot co dot uk changed: What|Removed |Added CC||timday at bottlenose dot ||demon dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
[Bug libfortran/29810] New: ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
This causes approximately 4400 failures in the gfortran testsuite. Here's the first: Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/ mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/ gfortran.dg/PR19754_2.f90 -O0 -pedantic-errors -L/mnt/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./li bgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty -lm -o ./PR19754_2.exe(timeout = 300) ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. FAIL: gfortran.dg/PR19754_2.f90 -O0 (test for excess errors) Excess errors: ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. -- Summary: ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp- hpux11.11/./libgfortran/.libs/libgfortran.sl Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #1 from danglin at gcc dot gnu dot org 2006-11-12 16:11 --- This symbol is in _mod_r16.o. I guess this points to: 2006-11-05 Francois-Xavier Coudert [EMAIL PROTECTED],org Paul Thomas [EMAIL PROTECTED] PR fortran/24518 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Use built_in fmod for both MOD and MODULO, if it is available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #2 from kargl at gcc dot gnu dot org 2006-11-12 16:22 --- Just curious. Do you file bug reports with HP about the lack of C99 long double libm functions? You need to add a fmodl function to c99_functions.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #3 from kargl at gcc dot gnu dot org 2006-11-12 16:36 ---
Here's an untested patch.
Index: configure.ac
===
--- configure.ac(revision 118613)
+++ configure.ac(working copy)
@@ -235,6 +249,7 @@ AC_CHECK_LIB([m],[cexpl],[AC_DEFINE([HAV
AC_CHECK_LIB([m],[fabsf],[AC_DEFINE([HAVE_FABSF],[1],[libm includes fabsf])])
AC_CHECK_LIB([m],[fabs],[AC_DEFINE([HAVE_FABS],[1],[libm includes fabs])])
AC_CHECK_LIB([m],[fabsl],[AC_DEFINE([HAVE_FABSL],[1],[libm includes fabsl])])
+AC_CHECK_LIB([m],[fmodl],[AC_DEFINE([HAVE_FMODL],[1],[libm includes fmodl])])
AC_CHECK_LIB([m],[cabsf],[AC_DEFINE([HAVE_CABSF],[1],[libm includes cabsf])])
AC_CHECK_LIB([m],[cabs],[AC_DEFINE([HAVE_CABS],[1],[libm includes cabs])])
AC_CHECK_LIB([m],[cabsl],[AC_DEFINE([HAVE_CABSL],[1],[libm includes cabsl])])
Index: intrinsics/c99_functions.c
===
--- intrinsics/c99_functions.c (revision 118613)
+++ intrinsics/c99_functions.c (working copy)
@@ -1159,3 +1159,17 @@ ctanl (long double complex a)
}
#endif
+#if !defined(HAVE_FMODL)
+#define HAVE_FMODL 1
+long double
+fmodl (long double x, long double y)
+{
+ if (y == 0)
+return 0;
+
+ /* Need to check that the result has the same sign as x and magnitude
+ less than the magnitude of y. */
+ return (x - floorl(x / y) * y;
+}
+#endif
+
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/29518] [4.0/4.1/4.2/4.3 Regression] rejects valid template argument, enums vs templates
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-12 16:43 --- (In reply to comment #12) From Aleksey Gurtovoy (co-author Boost.MPL): [wrt to this bug] Actually, no, enums in the bug's subject and reduced test case are a red herring. For example, this still fails for me on 4.1.1: Not really because that passes for me with 4.1.2 and 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29809] [4.1 Regression] Segmentation fault with 4.1.1 and 4.1-20061110
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-12 17:07 --- *** This bug has been marked as a duplicate of 28116 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29809
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-12 17:07 --- *** Bug 29809 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||chris_clayton at f1internet ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug java/29805] [4.2/4.3 Regression] Write past end of array in java/typeck.c
--- Comment #4 from daney at gcc dot gnu dot org 2006-11-12 17:12 --- Subject: Bug 29805 Author: daney Date: Sun Nov 12 17:12:13 2006 New Revision: 118724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118724 Log: PR java/29805 * typeck.c (build_java_array_type): Increase buffer sizes. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29805
[Bug java/29805] [4.2/4.3 Regression] Write past end of array in java/typeck.c
--- Comment #5 from daney at gcc dot gnu dot org 2006-11-12 17:15 --- Subject: Bug 29805 Author: daney Date: Sun Nov 12 17:14:52 2006 New Revision: 118725 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118725 Log: PR java/29805 * typeck.c (build_java_array_type): Increase buffer sizes. Modified: branches/gcc-4_2-branch/gcc/java/ChangeLog branches/gcc-4_2-branch/gcc/java/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29805
[Bug inline-asm/29808] [4.2 Regression] Error: suffix or operands invalid for `mov' when optimization is enabled
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-12 17:15 --- (In reply to comment #3) If the code is invalid, the fact that it compiles with -O0 is probably a bug... No it is not really a bug that it compiles at -O0 either becuase g means r+i so the register allocator in the -O0 case is selecting r while in the optimize case is selecting i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808
[Bug java/29805] [4.2/4.3 Regression] Write past end of array in java/typeck.c
--- Comment #6 from daney at gcc dot gnu dot org 2006-11-12 17:19 --- Fixed by the patch. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29805
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #36 from rakdver at gcc dot gnu dot org 2006-11-12 17:33 --- (In reply to comment #19) Created an attachment (id=12574) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574action=view) [edit] A patch This reverts the patch which triggers the problem and adds a testcase. I am running SPEC CPU 2006 now. I am going to commit this patch for now (once it passes bootstrap regtesting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug java/29805] [4.2/4.3 Regression] Write past end of array in java/typeck.c
-- daney at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29805
[Bug tree-optimization/13827] (a b) != (c b) should be transformed to ((a^c) b) !=0
--- Comment #4 from sayle at gcc dot gnu dot org 2006-11-12 18:41 --- Subject: Bug 13827 Author: sayle Date: Sun Nov 12 18:41:31 2006 New Revision: 118727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118727 Log: PR tree-optimization/13827 * fold-const.c (fold_binary) EQ_EXPR, NE_EXPR: Fold (XC) op (YC) as ((X^Y)C) op 0. * gcc.dg/fold-eqand-1.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/fold-eqand-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13827
[Bug tree-optimization/29777] missed optimization: model missing widen_mult* idioms for SSE
--- Comment #4 from ubizjak at gmail dot com 2006-11-12 18:44 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
[Bug tree-optimization/29791] [4.3 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-12 18:51 --- The difference between the 4.2 branch and the trunk is: On the trunk: # PARM_NOALIAS.12_38 = V_MAY_DEF PARM_NOALIAS.12_35; (*D.1004_16)[0] = D.1010_27; On the 4.2 branch: # SMT.15_38 = V_MAY_DEF SMT.15_37; (*D.918_16)[0] = D.924_27; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.2 |4.1.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug tree-optimization/13827] (a b) != (c b) should be transformed to ((a^c) b) !=0
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-12 18:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13827
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-12 19:38 --- Subject: Re: ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.l --- Comment #2 from kargl at gcc dot gnu dot org 2006-11-12 16:22 --- Just curious. Do you file bug reports with HP about the lack of C99 long double libm functions? I don't have a service contract that allows for filing bug reports with HP. There's no hope for hpux = 11.23. Don't know if HP will complete C99 support in 11.31. Although the PA-RISC architecture provides for long double support in hardware, this has not been implemented. So, I wonder if HP will bother with the C99 long double libm functions. The long double emulation code that's present in hpux caused various issues with Ada, so we don't use it anymore. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-12 19:58 --- This patch should fix the problem: Index: config/rs6000/rs6000.c === --- config/rs6000/rs6000.c (revision 118728) +++ config/rs6000/rs6000.c (working copy) @@ -8711,9 +8711,8 @@ altivec_init_builtins (void) decl = add_builtin_function (__builtin_altivec_mask_for_load, v16qi_ftype_long_pcvoid, ALTIVEC_BUILTIN_MASK_FOR_LOAD, - BUILT_IN_MD, NULL, - tree_cons (get_identifier (const), - NULL_TREE, NULL_TREE)); + BUILT_IN_MD, NULL, NULL); + TREE_READONLY (decl) = 1; /* Record the decl. Will be used by rs6000_builtin_mask_for_load. */ altivec_builtin_mask_for_load = decl; } I don't think we should be using attributes here really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug c++/29727] [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer for template member
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29727
[Bug c++/29728] [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer in template function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29728
[Bug c++/29729] [4.0/4.1/4.2/4.3 regression] ICE with template class in template function
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-11-12 20:38 --- From [temp.mem]: A local class shall not have member templates. Therefore, this is indeed invalid. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug c++/29730] [4.0/4.1/4.2/4.3 regression] ICE on invalid declaration of template member
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29730
[Bug c++/29731] [4.0/4.1/4.2/4.3 regression] ICE with statement expression as template parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29731
[Bug c++/29732] [4.0/4.1/4.2/4.3 regression] ICE on invalid friend declaration
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29732
[Bug c++/29733] [4.1/4.2/4.3 regression] ICE on initialization of function type
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug c++/29734] [4.0/4.1/4.2/4.3 regression] ICE with vector in switch condition
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29734
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #5 from acme at mandriva dot com 2006-11-12 20:39 --- (In reply to comment #4) The only thing left from __task_rq_lock is a label. SNIP task_cpu were inlined and we constant proped the value of rq the first of the way through the function which we inlined this to. OK, I thought that this was due to something like what you described, even not knowing that much about gcc internals, but I thought that even in this case the DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow me to do what I want with my tools :-\ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
[Bug c++/29735] [4.0/4.1/4.2/4.3 regression] ICE on main returning vector
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29735
[Bug c/29736] [4.0/4.1/4.2/4.3 regression] ICE on duplicate vector attribute
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29736
