Re: at web: /install/specific.html
On Tue, 1 Mar 2005, Alec Voropay wrote: > It seems, the local on the GCC web page > http://gcc.gnu.org/install/specific.html > does not work due to wrong HTML format. I'm afraid that, originally, I didn't understand what you meant by this, but I believe that I do now and thus I committed a fix for this problem two days ago. If you're still seeing this, would you mind providing some more details on what does not work for you? Something like "When I select the link labeled X, I would expect Y to happen, but actually see Z." would be helpful in that case. Thanks, Gerald
GCC 3.3 status
Hello Gaby, do you still confirm the release date which was last reported here: http://gcc.gnu.org/ml/gcc/2005-01/msg01253.html that is, will GCC 3.3.6 released on April, 30th? And will it be the last release of the GCC 3.3 series? Thanks, Giovanni Bajo
Re: Packaging error in 4.0RC1 docs? [was RE: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0 ]
On Tue, 12 Apr 2005, Dave Korn wrote: >> When I look in gcc-4.0.0-20050410/INSTALL at specific.html > Oh, BTW, it seems the internal links in that page are b0rked in the usual > sort of way, owing to the mangling of 'special' characters. A link like: > > *-ibm-aix* > > doesn't actually link up with an anchor like > > > > name="_002a_002dibm_002daix_002a">*-ibm-aix* This should work now; I committed a patch a few days ago. > Oh, and there are TOC entries for chapters that don't exist at all, such > as > > powerpc-*-eabiaix I removed two such obsolete TOC entries in specific.html; if you are aware of any further issues, please let us know. Gerald
Re: at web: /install/specific.html
On Wednesday 20 April 2005 06:12 am, Gerald Pfeifer wrote: > On Tue, 1 Mar 2005, Alec Voropay wrote: > > It seems, the local on the GCC web page > > http://gcc.gnu.org/install/specific.html > > does not work due to wrong HTML format. > > I'm afraid that, originally, I didn't understand what you meant by this, > but I believe that I do now and thus I committed a fix for this problem > two days ago. I think he meant it has the wrong doctype. That is clearly an xhtml document, but it has an html4 doctype. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgphonpeKFB6G.pgp Description: PGP signature
makeinfo 4.8 generates non-standard HTML for @emph{..@samp{..}..}
In the GCC documentation (gcc/doc/install.texi) we have the following
texinfo snippet
@emph{You should substitute @samp{i686} in the above command with the
appropriate processor for your host.}
makeinfo 4.8 translates this to
You should substitute `i686
' in the above command with the appropriate processor
for your host.
which is not valid HTML 4.01 nor XHTML 1.0 transitional according to
validator.w3.org.
(The original file is at .)
Gerald
Re: at web: /install/specific.html
On Wed, 20 Apr 2005, Patrick McFarland wrote: >>> http://gcc.gnu.org/install/specific.html > I think he meant it has the wrong doctype. That is clearly an xhtml > document, but it has an html4 doctype. If you pass this page through validator.w3.org, you'll see that this is clearly *not* an XHTML document, not even XHTML 1.0 transitional. It's not an HTML 4.01 document, either, but I believe this is only due to a minor makeinfo bug which I just reported to the authors. Gerald
Re: makeinfo 4.8 generates non-standard HTML for @emph{..@samp{..}..}
Hi Gerald, You should substitute `i686 ' in the above command with the appropriate processor for your host. Thanks for the report, I'll work on fixing that. karl
Re: GCC 3.3 status
On Wed, 20 Apr 2005, Giovanni Bajo wrote: | Hello Gaby, | | do you still confirm the release date which was last reported here: | http://gcc.gnu.org/ml/gcc/2005-01/msg01253.html | | that is, will GCC 3.3.6 released on April, 30th? And will it be the last | release of the GCC 3.3 series? All those information are right. More on that later today. | | Thanks, | Giovanni Bajo | | -- Gabriel Dos Reis [EMAIL PROTECTED] Texas A&M University -- Computer Science Department 301, Bright Building -- College Station, TX 77843-3112
Hey? Where did the intrinsics go?
As I have written in an earlier post here, I'm trying to vectorize some loops with intrinsics and I have also got a gcc 4.1 snapshot (20050410). However when I try to compile my code with the gcc-4.1 snapshot I get: /msys/1.0/home/mingw/bin/gcc.exe -g -Wall -O3 -msse -mtune=pentium3 -DHAVE_CONFIG_H -I. -I.. -c -o neuralnet.o neuralnet.c neuralnet.c: In function 'Evaluate': neuralnet.c:492: warning: implicit declaration of function '__builtin_ia32_loadaps' neuralnet.c:492: error: incompatible types in assignment neuralnet.c:493: error: incompatible types in assignment And so on Am I missing an header include somewhere...?? -Øystein
Re: Reload Issue -- I can't believe we haven't hit this before
> Think about it for a while -- given a SET where the SET_SRC is a > pseudo which did not get a hard register and is equivalenced to > a read-only memory location, then the SET must be dead as it > can only be setting the memory location to the value already > in the memory location. Was that long enough? :-) However, my reaction has not changed since yesterday: did you mean SET_DEST? -- Eric Botcazou
Re: at web: /install/specific.html
On Wed, Apr 20, 2005 at 12:12:21PM +0200, Gerald Pfeifer wrote: > > I'm afraid that, originally, I didn't understand what you meant by this, > but I believe that I do now and thus I committed a fix for this problem > two days ago. Thank you. As I see, you've changed all *-* in anchors with x-x . It works. Thanks again. -- -=AV=-
Re: Reload Issue -- I can't believe we haven't hit this before
On Wed, 2005-04-20 at 17:18 +0200, Eric Botcazou wrote: > > Think about it for a while -- given a SET where the SET_SRC is a > > pseudo which did not get a hard register and is equivalenced to > > a read-only memory location, then the SET must be dead as it > > can only be setting the memory location to the value already > > in the memory location. > > Was that long enough? :-) :-) > However, my reaction has not changed since > yesterday: did you mean SET_DEST? Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo which did not get a hard register and is equivalent to a readonly memory location that the insn is useless? Jeff
Re: Hey? Where did the intrinsics go?
Ãystein Johansen <[EMAIL PROTECTED]> writes: > As I have written in an earlier post here, I'm trying to vectorize > some loops with intrinsics and I have also got a gcc 4.1 snapshot > (20050410). However when I try to compile my code with the gcc-4.1 > snapshot I get: > > /msys/1.0/home/mingw/bin/gcc.exe -g -Wall -O3 -msse -mtune=pentium3 > -DHAVE_CONFIG_H -I. -I.. -c -o neuralnet.o neuralnet.c > neuralnet.c: In function 'Evaluate': > neuralnet.c:492: warning: implicit declaration of function > '__builtin_ia32_loadaps' > neuralnet.c:492: error: incompatible types in assignment > neuralnet.c:493: error: incompatible types in assignment > > And so on > > Am I missing an header include somewhere...?? Looks like it disappeared here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00613.html I think the list of i386 builtin functions is now out of date in the documentation. Ian
Re: Reload Issue -- I can't believe we haven't hit this before
> Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo > which did not get a hard register and is equivalent to a readonly > memory location that the insn is useless? Yes, I think so: being equivalenced implies that there was a REG_EQUIV note, so the insn cannot do anything else than setting the pseudo to the value it is already equivalenced to. -- Eric Botcazou
Re: Reload Issue -- I can't believe we haven't hit this before
On Wed, 2005-04-20 at 18:51 +0200, Eric Botcazou wrote: > > Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo > > which did not get a hard register and is equivalent to a readonly > > memory location that the insn is useless? > > Yes, I think so: being equivalenced implies that there was a REG_EQUIV note, > so the insn cannot do anything else than setting the pseudo to the value it > is already equivalenced to. Right. So, in theory all we have to do is delete these insns. The problem is detection and elimination of these insns. It's relatively easy to scan the register state to find pseudos which were not assigned a hard reg and which are equivalenced to a readonly memory location. If you find any, then you scan the IL and kill the offending insns. Seems trivial. Unfortunately, it's not that simple. The relatively unstructured nature of RTL means the offending assignment to the pseudo could appear in a multitude of contexts, including simple assignments or part of an arbitrarily complex parallel. It's probably not safe to simply remove the assignment if it appears in a PARALLEL as doing so may create an unrecognizable insn. Ugh. If we find such cases we could fall back to not recording the equivalence. But what worries me even more is spilling. Say a pseudo has a hard reg assigned and is also equivalent to a readonly memory location. Reload then decides to spill the pseudo out of the hard reg because the hard reg was needed for something else. When that occurs we'd have to scan affected live range of the pseudo for assignments into the pseudo and remove them like I've suggested above. But that brings another set of bookkeeping problems -- we're twiddling reg_equiv_XXX significantly later in the reload process, and I'm not sure how safe that's going to be. Given how rare this situation occurs, I'm leaning towards simply ignoring the problematical equivalences. jeff
Re: Reload Issue -- I can't believe we haven't hit this before
> Jeffrey A Law wrote: > ... > But what worries me even more is spilling. Say a pseudo has a hard reg > assigned and is also equivalent to a readonly memory location. Reload > then decides to spill the pseudo out of the hard reg because the hard > reg was needed for something else. When that occurs we'd have to scan > affected live range of the pseudo for assignments into the pseudo and > remove them like I've suggested above. But that brings another set of > bookkeeping problems -- we're twiddling reg_equiv_XXX significantly > later in the reload process, and I'm not sure how safe that's going to > be. > > Given how rare this situation occurs, I'm leaning towards simply > ignoring the problematical equivalences. Wouldn't the following be true for all pseduo's equated to readonly values?: - if given a hard reg assignment, it may be spilled and reloaded just as any value may (thereby the pseudo is now equated with the spilled value), or alternatively, it's not literally spilled, it just loses it's hard reg assignment, and needs to be regenerated as required, as below): - if not given a hard reg assignment, but referenced, it's reference is equivalent to (mem (symbol ))) with MEM_READONLY_P == true; were if its value ends up being stored directly into an allocated hard register, it now also has a hard-reg assignment, which is treated as above if the hard is reallocated.
Re: Hey? Where did the intrinsics go?
Looks like it disappeared here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00613.html I think the list of i386 builtin functions is now out of date in the documentation. The following differences now exist between the documentation and the current 4.1 x86 code. I do not know whether all of the changes were intentional. Documented, but doesn't exist: __builtin_ia32_cmpnlts __builtin_ia32_loadaps __builtin_ia32_loadddup __builtin_ia32_loadsss ** __builtin_ia32_movddup __builtin_ia32_pextrw __builtin_ia32_pfrsqrtit1 __builtin_ia32_pinsrw __builtin_ia32_storeaps __builtin_ia32_storess ** the docs for loadss have a typo as noted by PR target/20049 While the following exist without being documented: __builtin_ia32_addpd __builtin_ia32_addsd __builtin_ia32_andnpd __builtin_ia32_andpd __builtin_ia32_clflush __builtin_ia32_cmpeqpd __builtin_ia32_cmpeqsd __builtin_ia32_cmpgepd __builtin_ia32_cmpgtpd __builtin_ia32_cmplepd __builtin_ia32_cmplesd __builtin_ia32_cmpltpd __builtin_ia32_cmpltsd __builtin_ia32_cmpneqpd __builtin_ia32_cmpneqsd __builtin_ia32_cmpngepd __builtin_ia32_cmpngess __builtin_ia32_cmpngtpd __builtin_ia32_cmpngtss __builtin_ia32_cmpnlepd __builtin_ia32_cmpnlesd __builtin_ia32_cmpnltpd __builtin_ia32_cmpnltsd __builtin_ia32_cmpnltss __builtin_ia32_cmpordpd __builtin_ia32_cmpordsd __builtin_ia32_cmpunordpd __builtin_ia32_cmpunordsd __builtin_ia32_comisdeq __builtin_ia32_comisdge __builtin_ia32_comisdgt __builtin_ia32_comisdle __builtin_ia32_comisdlt __builtin_ia32_comisdneq __builtin_ia32_cvtdq2pd __builtin_ia32_cvtdq2ps __builtin_ia32_cvtpd2dq __builtin_ia32_cvtpd2pi __builtin_ia32_cvtpd2ps __builtin_ia32_cvtpi2pd __builtin_ia32_cvtps2dq __builtin_ia32_cvtps2pd __builtin_ia32_cvtsd2si __builtin_ia32_cvtsd2si64 __builtin_ia32_cvtsd2ss __builtin_ia32_cvtsi2sd __builtin_ia32_cvtsi642sd __builtin_ia32_cvtsi642ss __builtin_ia32_cvtss2sd __builtin_ia32_cvtss2si64 __builtin_ia32_cvttpd2dq __builtin_ia32_cvttpd2pi __builtin_ia32_cvttps2dq __builtin_ia32_cvttsd2si __builtin_ia32_cvttsd2si64 __builtin_ia32_cvttss2si64 __builtin_ia32_divpd __builtin_ia32_divsd __builtin_ia32_emms __builtin_ia32_ldmxcsr __builtin_ia32_lfence __builtin_ia32_loaddqu __builtin_ia32_loadhpd __builtin_ia32_loadlpd __builtin_ia32_loadupd __builtin_ia32_maskmovdqu __builtin_ia32_maxpd __builtin_ia32_maxsd __builtin_ia32_mfence __builtin_ia32_minpd __builtin_ia32_minsd __builtin_ia32_movmskpd __builtin_ia32_movntdq __builtin_ia32_movnti __builtin_ia32_movntpd __builtin_ia32_movsd __builtin_ia32_mulpd __builtin_ia32_mulsd __builtin_ia32_orpd __builtin_ia32_packssdw128 __builtin_ia32_packsswb128 __builtin_ia32_packuswb128 __builtin_ia32_paddb128 __builtin_ia32_paddd128 __builtin_ia32_paddq __builtin_ia32_paddq128 __builtin_ia32_paddsb128 __builtin_ia32_paddsw128 __builtin_ia32_paddusb128 __builtin_ia32_paddusw128 __builtin_ia32_paddw128 __builtin_ia32_pand128 __builtin_ia32_pandn128 __builtin_ia32_pavgb128 __builtin_ia32_pavgw128 __builtin_ia32_pcmpeqb128 __builtin_ia32_pcmpeqd128 __builtin_ia32_pcmpeqw128 __builtin_ia32_pcmpgtb128 __builtin_ia32_pcmpgtd128 __builtin_ia32_pcmpgtw128 __builtin_ia32_pfrsqit1 __builtin_ia32_pmaddwd __builtin_ia32_pmaddwd128 __builtin_ia32_pmaxsw128 __builtin_ia32_pmaxub128 __builtin_ia32_pminsw128 __builtin_ia32_pminub128 __builtin_ia32_pmovmskb128 __builtin_ia32_pmulhuw128 __builtin_ia32_pmulhw128 __builtin_ia32_pmullw128 __builtin_ia32_pmuludq __builtin_ia32_pmuludq128 __builtin_ia32_por128 __builtin_ia32_psadbw128 __builtin_ia32_pshufd __builtin_ia32_pshufhw __builtin_ia32_pshuflw __builtin_ia32_pshufw __builtin_ia32_pslld __builtin_ia32_pslld128 __builtin_ia32_pslldi128 __builtin_ia32_pslldqi128 __builtin_ia32_psllq __builtin_ia32_psllq128 __builtin_ia32_psllqi128 __builtin_ia32_psllw __builtin_ia32_psllw128 __builtin_ia32_psllwi128 __builtin_ia32_psrad __builtin_ia32_psrad128 __builtin_ia32_psradi128 __builtin_ia32_psraw __builtin_ia32_psraw128 __builtin_ia32_psrawi128 __builtin_ia32_psrld __builtin_ia32_psrld128 __builtin_ia32_psrldi128 __builtin_ia32_psrldqi128 __builtin_ia32_psrlq __builtin_ia32_psrlq128 __builtin_ia32_psrlqi128 __builtin_ia32_psrlw __builtin_ia32_psrlw128 __builtin_ia32_psrlwi128 __builtin_ia32_psubb128 __builtin_ia32_psubd128 __builtin_ia32_psubq __builtin_ia32_psubq128 __builtin_ia32_psubsb128 __builtin_ia32_psubsw128 __builtin_ia32_psubusb128 __builtin_ia32_psubusw128 __builtin_ia32_psubw128 __builtin_ia32_punpckhbw128 __builtin_ia32_punpckhdq128 __builtin_ia32_punpckhqdq128 __builtin_ia32_punpckhwd128 __builtin_ia32_punpcklbw128 __builtin_ia32_punpckldq128 __builtin_ia32_punpcklqdq128 __builtin_ia32_punpcklwd128 __builtin_ia32_pxor128 __builtin_ia32_shufpd __builtin_ia32_sqrtpd __builtin_ia32_sqrtsd __builtin_ia32_stmxcsr __builtin_ia32_storedqu __builtin_ia32_storeupd __builtin_ia32_subpd __builtin_ia32_subsd __builtin_ia32_ucomisdeq __builtin_ia32_ucomisdge __builtin_ia32_ucomisdgt __builtin_ia32_ucomisdle __builtin_ia32_ucomisdlt __builtin_ia32_ucomisdneq __builtin_ia
Re: Hey? Where did the intrinsics go?
> > > Looks like it disappeared here: > > http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00613.html > > > > I think the list of i386 builtin functions is now out of date in the > > documentation. > > The following differences now exist between the documentation and the > current 4.1 x86 code. > > I do not know whether all of the changes were intentional. > > Documented, but doesn't exist: > > __builtin_ia32_cmpnlts > __builtin_ia32_loadaps > __builtin_ia32_loadddup > __builtin_ia32_loadsss ** > __builtin_ia32_movddup > __builtin_ia32_pextrw > __builtin_ia32_pfrsqrtit1 > __builtin_ia32_pinsrw > __builtin_ia32_storeaps > __builtin_ia32_storess > > > ** the docs for loadss have a typo as noted by PR target/20049 > > While the following exist without being documented: Yes this was intentional, you should not be using the builtin functions, instead use intrinsics from the header files. -- Pinski
Re: Reload Issue -- I can't believe we haven't hit this before
Sorry, to be clearer, what I meant by: > From: Paul Schlie <[EMAIL PROTECTED]> > .. (thereby the pseudo is now equated with the spilled value), or ... was: (thereby the pseudo is now equated with an allocated temporary memory location, now storing the spilled value), or ...
Re: Hey? Where did the intrinsics go?
Andrew Pinski wrote: Yes this was intentional, you should not be using the builtin functions, instead use intrinsics from the header files. I've just rewritten the code to use the intrinsics from the header files (xmmintrin.h). It now reads _mm_foo() instead of __builtin_ia32_foo(). The problem now have been reported to bug item #21126. :-( Thanks, -Øystein
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
On 14 Apr 2005, John David Anglin spake:
>> : build/genattrtab
>> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/
>> rs6000.md > tmp-attrtab.c
>> :
>> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
>
> You need to increase the application limits for data on your system.
No, something is very wrong here, I think. genattrtab has allocated
*4Gb*!
Not even the monster which is x86 needs anywhere near that much storage
when running genattrtab.
Whether this is a genattrtab bug or a genattrtab miscompilation is a
question best left to those with access to this platform (i.e, I
can't answer it).
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
On Wed, Apr 20, 2005 at 08:16:22PM +0100, Nix wrote: > On 14 Apr 2005, John David Anglin spake: > >> : build/genattrtab > >> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > >> rs6000.md > tmp-attrtab.c > >> : > >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes > > > > You need to increase the application limits for data on your system. > > No, something is very wrong here, I think. genattrtab has allocated > *4Gb*! > > Not even the monster which is x86 needs anywhere near that much storage > when running genattrtab. > > Whether this is a genattrtab bug or a genattrtab miscompilation is a > question best left to those with access to this platform (i.e, I > can't answer it). Note that that's a total allocation, not a peak allocation. The 4GB total isn't unlikely, with all the PPC DFAs. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Hey? Where did the intrinsics go?
On 4/20/05, Andrew Pinski <[EMAIL PROTECTED]> wrote: > Yes this was intentional, you should not be using the builtin functions, > instead use intrinsics from the header files. Now that intrinsics are first class citizens it would be a real plus if someone could convince gcc to not spit horrors like that, ever (but perhaps for debugging?): 00400840 <_mm_setzero_ps()>: 400840: xorps %xmm0,%xmm0 400843: retq ... 00400850 <_mm_min_ss(float __vector, float __vector)>: 400850: minss %xmm1,%xmm0 400854: retq ... 00400860 <_mm_max_ss(float __vector, float __vector)>: 400860: maxss %xmm1,%xmm0 400864: retq ... 00400870 <_mm_sub_ps(float __vector, float __vector)>: 400870: subps %xmm1,%xmm0 400873: retq ... 00400880 <_mm_mul_ps(float __vector, float __vector)>: 400880: mulps %xmm1,%xmm0 400883: retq ... etc ad nauseam and then the final blow... 00400980 : 400980: push %r15 400982: mov%rcx,%r15 400985: push %r14 400987: mov%rdx,%r14 40098a: push %r13 40098c: push %r12 40098e: mov%rdi,%r12 400991: mov$0x5016b0,%edi 400996: lea0x10(%r12),%r13 40099b: push %rbx 40099c: mov%rsi,%rbx 40099f: sub$0x310,%rsp 4009a6: callq 4008d0 <_mm_load_ps(float const*)> 4009ab: movaps %xmm0,0x2d0(%rsp) 4009b3: mov$0x5016c0,%edi 4009b8: callq 4008d0 <_mm_load_ps(float const*)> 4009bd: movaps %xmm0,0x2c0(%rsp) 4009c5: mov%rbx,%rdi 4009c8: callq 4008d0 <_mm_load_ps(float const*)> 4009cd: movaps %xmm0,0x2b0(%rsp) 4009d5: lea0x10(%rbx),%rdi 4009d9: lea0x300(%rsp),%rbx 4009e1: callq 4008d0 <_mm_load_ps(float const*)> 4009e6: movaps %xmm0,0x2a0(%rsp) 4009ee: mov%r12,%rdi etc... Excerpts from a x86-64 bin with gcc 4120050410 at -O3, but i've seen it happen under various conditions & compile flags or compiler versions on straight x86 too. The only way i know to fix it is to tinker with params. Eek.
Typo in online GCJ docs.
In page:
http://gcc.gnu.org/onlinedocs/gcj/Objects-and-Classes.html
- Specifically, 8-bite and 16-bit native types
+ Specifically, 8-bit and 16-bit native types
On the same page there is a Java example that will not compile, I found and
fixed 3 bugs; Please replace with:
public class Int
{
public int i;
public Int(int i) { this.i = i; }
public static Int zero = new Int(0);
}
On page:
http://gcc.gnu.org/onlinedocs/gcj/Class-Initialization.html
Both JvInitClass and Jv_InitClass are used; which one is it?
Please forward to the maintainer or if you can, fix it in the source.
Thanks!
--
Thomas Zander
pgpfVr6uF3Sih.pgp
Description: PGP signature
gcc-3.3-20050420 is now available
Snapshot gcc-3.3-20050420 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050420/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.3 CVS branch with the following options: -rgcc-ss-3_3-20050420 You'll find: gcc-3.3-20050420.tar.bz2 Complete GCC (includes all of below) gcc-core-3.3-20050420.tar.bz2 C front end and core compiler gcc-ada-3.3-20050420.tar.bz2 Ada front end and runtime gcc-g++-3.3-20050420.tar.bz2 C++ front end and runtime gcc-g77-3.3-20050420.tar.bz2 Fortran 77 front end and runtime gcc-java-3.3-20050420.tar.bz2 Java front end and runtime gcc-objc-3.3-20050420.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.3-20050420.tar.bz2The GCC testsuite Diffs from 3.3-20050413 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
emit_no_conflict_block breaks some conditional moves
My port failed the DImode part of the rotate regression-tests (gcc.c-torture/execute/20020508-[123].c). I found that emit_no_conflict_block() reordered insns gen'd by expand_doubleword_shift() in a way that violated dependency between compares and associated conditional-move insns that had the target register as destination. AFAICT, any other port (arc, m32r, v850, xtensa) that emits a cmpsi followed by movsicc and has no native DImode shift insns will be subject to this bug also. Any hints on the proper approach? My initial idea is to make emit_no_conflict_block() maintain pairing between cmpsi and movsicc, which will work as long as cmpsi's operands are never clobbered. Ultimately, I'll side-step the bug by defining expands or splits for DImode shifts & rotates, but I'd like to see emit_no_conflict_block() fixed. Comments? Greg
Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)
Martin Koegler wrote: > Placing variables in a specfic section is only a part of the problem. I am aware of that. There are already many targets that have special handling for section attributes, that result in different code being generated when a section attribute is present. Mostly these have to do with generating different kinds of address and/or addressing modes though, and your case sounds more complicated. Handling different kinds of addresses can be done by setting SYMBOL_REF_FLAGS on a symbol_ref. My prototype for the m68hc05 does currently the following (based on GCC 4.1): It looks like a reasonable plan. It relies on MEM_EXPR always being set, which may not be true. But if there are places creating MEMs from decls without setting MEM_EXPR, then they probably should be fixed. MEMs created for things like spills to stack slots may not have MEM_EXPR set, but then they can't possibly have the eeprom attribute either, so that is OK. This could be a maintenance problem if other developers make changes and forget to keep the MEM_EXPR fields accurate. The more we use the MEM_EXPR fields, the less of a problem this will be. + if (expr == NULL_TREE) +expr = t; This is setting MEM_EXPR to a type. I see that this does work by accident, because MEM_EXPR can be either a decl or a COMPONENT_REF, and all of the code that excludes COMPONENT_REFs will also happen to excludes types. I don't think it is a good idea in general though. Overloading a field to have either an expression or a type may result in confusion later. Presumably this is only a problem because some MEMs don't have the MEM_EXPR field set, in which case a better solution is to find the places that forget to set it and fix them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: static inline functions disappear - incorrect static initialiser analysis?
Daniel Towner wrote: This no longer appears to be the case? `assemble_name' is still called with `fn', and correctly marks `fn' as being referenced, but no body is ever emitted. -fno-unit-at-a-time might help. This disables some of the cgraph optimizations. This will probably go away eventually. Do I now need to do something more than just calling assemble_name to get gcc to output the function body in such a case? No. cgraph should determine by itself that the function is needed. The assemble_name call shouldn't be relevant here. /* ??? If the assembler name is set by hand, it is possible to assemble the name later after finalizing the function and the fact is noticed in assemble_name then. This is arguably a bug. */ I think this is referring to use of __asm__ to change the name of a function in unexpected ways. It doesn't have anything to do with your problem. What you should do here is pick a target that works, and debug cgraph to see how it works. Then debug your target to see why it doesn't. The sequence of events should be something like: 1) We walk the tree for main, and note that main calls fn. 2) We emit main because it is extern. 3) We then emit everything that main calls, which includes fn. I won't hazard a guess as to what is wrong, as I don't see how this could be failing. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Call into a function?
Hi, A code segment from Itanium platform. Note the instruction at 0x4722, what does this mean? I'vd gdbed the program, r2=0, so 0x4722 just not executes. This puzzles me because I am working on analyzing elfs depends on br Instructions. Can I call into the internal of a function? Thanks, Zhenyu Dump of assembler code for function gmon_initializer: 0x46f0 :[MMB] alloc r34=ar.pfs,3,3,0 0x46f1 :addl r3=64,r1 0x46f2 :nop.b 0x0 0x4700 : [MFI] mov r32=r1 0x4701 : nop.f 0x0 0x4702 : mov r33=b0;; 0x4710 : [MMI] ld8 r2=[r3];; 0x4711 : cmp.eq p8,p9=0,r2 0x4712 : nop.i 0x0 0x4720 : [BBB] nop.b 0x0 0x4721 : (p08) br.cond.dpnt.few 0x4740 0x4722 : br.call.sptk.many b0=0x4720 ;; ~ 0x4730 : [MFB] mov r1=r32 0x4731 : nop.f 0x0 0x4732 : nop.b 0x0 0x4740 : [MIB] nop.m 0x0 0x4741 : mov.i ar.pfs=r34 0x4742 : nop.b 0x0 0x4750 : [MIB] nop.m 0x0 0x4751 : mov b0=r33 0x4752 : br.ret.sptk.many b0;;
Re: RFA: .opt files for x86, darwin and lynxos
> - i386.h provides undocumented -mwindows and -mdll options. > I've put these in their own file (dummy-windows.opt) so that > cygwin and mingw can provide properly-documented versions. which means it is likely that Kenner and/or ACT wrote the patch. I didn't write it. I have a vague recollection it came from Microsoft, but could be wrong.
Re: RFC: ms bitfields of aligned basetypes
Joern RENNECKE wrote: required for Tal16bool. Should we enforce that any storage element allocated for a run of ms-bitfields get the full alignment of the basetype, even when it exceeds the size of the basetype and of BIGGEST_ALIGNMENT? Obviously, we should do the exact same thing that the microsoft compiler does. That is the whole point of -mms-bitfields. If we can't generate an equivalent testcase for the microsoft compiler, because it doesn't have aligned attributes or equivalent, then we can do whatever seems to make sense. It isn't clear from your message what the current behaviour is, whether there is any actual problem with the current behaviour, or what fix if any you think is right. Limiting alignment to BIGGEST_ALIGNMENT seems reasonable if there is a problem that needs to be fixed, and microsoft doesn't specify the behaviour here. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Unnesting of nested subreg expressions
Björn Haase wrote: The mid-end seems not to be able to simplify nested subreg expressions. I.e. it seems that there is no known transformation (subreg:QI (subreg:HI (reg:SI xx) 0) 0) Nested subregs aren't valid. You should refrain from creating them. (define_expand "xorhi3" [(set (subreg:QI (match_operand:HI 0 "register_operand" "=r") 0) (xor:QI (subreg:QI (match_operand:HI 1 "register_operand" "%0") 0) (subreg:QI (match_operand:HI 2 "register_operand" "r") 0))) (set (subreg:QI (match_dup 0) 1) (xor:QI (subreg:QI (match_dup 1) 1) (subreg:QI (match_dup 2) 1)))] If you have 16-bit registers, then I don't think there is any way to make this work as written. Intra-register high-part subregs aren't generally valid either. A high-part subreg is generally only valid when it is an entire-register of a multi-register value. You will have to use some other kind of rtl here, such as shift and masks, or zero_extract. It seems that the cleanest solution would be to teach gcc how to unnest subregs. Therefore my question: Is this possible and where would be the place for doing this? Or you can fix your expander to stop creating nested subregs. That is proabably much simpler than trying to teach the rest of the compiler to accept them. You can't rely on the fact that any expanded rtl will get simplified, so if we allow nested subregs, then everyplace that handles them needs to accept them, and that means an awful lot of code will have to change. BTW. I have stepped over a similar issue when using the gen_highpart and gen_lowpart functions for splitters after reload. I can't comment without details. are working on a label reference immediate operand. It seems that in their present form gen_lowpart and gen_highpart should be used only in DI-SI-mode splitters since then there is no danger that the DI mode expression itself is a subreg of an even larger mode. Except that the DImode expression could be a paradoxical subreg of a smaller mode, in which case you might have similar problems. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Whirlpool oopses in 2.6.11 and 2.6.12-rc2
Denis Vlasenko wrote: Yes. wp512_process_buffer() was using 3k of stack if compiled with -O2. The wp512.c I appended (sans table at top) is instrumented to show it. Use "make crypto/wp512.s". See http://gcc.gnu.org/bugs.html for info on reporting gcc bugs. We need a testcase that we can use to reproduce the problem. The code sample you gave can't be compiled, because it relies on types that aren't defined in the code sample. You also left out other important info such as what target you are compiling for. I'm guessing this is some linux kernel code, but it would still be helpful to have a self-contained testcase to make it easier for us to look at this. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Call into a function?
On Thu, Apr 21, 2005 at 10:41:40AM +0800, Zhenyu Guo wrote: > Hi, > A code segment from Itanium platform. > Note the instruction at 0x4722, what does this mean? > I'vd gdbed the program, r2=0, so 0x4722 just not executes. > This puzzles me because I am working on analyzing elfs depends on br > Instructions. Can I call into the internal of a function? I don't know anything about ia64, but it looks like you are looking at an unrelocated instruction; notice that it's branching to basically the same place it comes from. Objdump and readelf can help you look at the relocations, if any. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Call into a function?
Zhenyu Guo wrote: 0x4720 : [BBB] nop.b 0x0 0x4721 : (p08) br.cond.dpnt.few 0x4740 0x4722 : br.call.sptk.many b0=0x4720 ;; Most likely this means that you are looking at unlinked (i.e. unrelocated) code. Did you run objdump on a .o file? In this case, the actual call address is in the relocation. Try objdump -r and you will see a relocation for the address 0x4722 that contains the actual call target. Also try objdump -r -d. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
转发: Call into a function?
Not really. Here is my options: gcc --static test.c -o test Thx! -邮件原件- 发件人: James E Wilson [mailto:[EMAIL PROTECTED] 发送时间: 2005年4月21日 11:32 收件人: Zhenyu Guo 抄送: gcc@gcc.gnu.org 主题: Re: Call into a function? Zhenyu Guo wrote: > 0x4720 : [BBB] nop.b 0x0 > 0x4721 : (p08) > br.cond.dpnt.few 0x4740 > 0x4722 : br.call.sptk.many > b0=0x4720 ;; Most likely this means that you are looking at unlinked (i.e. unrelocated) code. Did you run objdump on a .o file? In this case, the actual call address is in the relocation. Try objdump -r and you will see a relocation for the address 0x4722 that contains the actual call target. Also try objdump -r -d. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Mike Stump named as Objective-C/Objective-C++ maintainer
The GCC Steering Committee has appointed Mike Stump as maintainer of the Objective-C and Objective-C++ front ends. Mike will work with Ziemowit Laski, who remains a maintainer of these front ends as well. Thanks, Mike, for volunteering for this job. Also, Mike, please add yourself to the MAINTAINERS file in the appropriate place. Joe
Re: Whirlpool oopses in 2.6.11 and 2.6.12-rc2
On Thursday 21 April 2005 06:16, James E Wilson wrote:
> Denis Vlasenko wrote:
> > Yes. wp512_process_buffer() was using 3k of stack if compiled with -O2.
> > The wp512.c I appended (sans table at top) is instrumented to show it.
> > Use "make crypto/wp512.s".
>
> See
> http://gcc.gnu.org/bugs.html
> for info on reporting gcc bugs.
>
> We need a testcase that we can use to reproduce the problem. The code
> sample you gave can't be compiled, because it relies on types that
> aren't defined in the code sample.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21141
Testcase:
/*
Excessive stack usage:
gcc3.4.3 -O2:
wp512_process_buffer:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$3516, %esp
^
gcc3.4.3 -Os:
wp512_process_buffer:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$588, %esp
*/
#define WP512_DIGEST_SIZE 64
#define WP384_DIGEST_SIZE 48
#define WP256_DIGEST_SIZE 32
#define WP512_BLOCK_SIZE 64
#define WP512_LENGTHBYTES 32
#define WHIRLPOOL_ROUNDS 10
typedef unsigned char u8;
typedef unsigned u32;
typedef unsigned long long u64;
struct wp512_ctx {
u8 bitLength[WP512_LENGTHBYTES];
u8 buffer[WP512_BLOCK_SIZE];
int bufferBits;
int bufferPos;
u64 hash[WP512_DIGEST_SIZE/8];
};
static const u64 C0[256];
#define C1 C0
#define C2 C0
#define C3 C0
#define C4 C0
#define C5 C0
#define C6 C0
#define C7 C0
#define rc C0
void wp512_process_buffer(struct wp512_ctx *wctx) {
int r;
u64 K[8];/* the round key */
u64 block[8];/* mu(buffer) */
u64 state[8];/* the cipher state */
u64 L[8];
for (r = 1; r <= WHIRLPOOL_ROUNDS; r++) {
L[0] = C0[(int)(K[0] >> 56) ] ^
C1[(int)(K[7] >> 48) & 0xff] ^
C2[(int)(K[6] >> 40) & 0xff] ^
C3[(int)(K[5] >> 32) & 0xff] ^
C4[(int)(K[4] >> 24) & 0xff] ^
C5[(int)(K[3] >> 16) & 0xff] ^
C6[(int)(K[2] >> 8) & 0xff] ^
C7[(int)(K[1] ) & 0xff] ^
rc[r];
L[1] = C0[(int)(K[1] >> 56) ] ^
C1[(int)(K[0] >> 48) & 0xff] ^
C2[(int)(K[7] >> 40) & 0xff] ^
C3[(int)(K[6] >> 32) & 0xff] ^
C4[(int)(K[5] >> 24) & 0xff] ^
C5[(int)(K[4] >> 16) & 0xff] ^
C6[(int)(K[3] >> 8) & 0xff] ^
C7[(int)(K[2] ) & 0xff];
L[2] = C0[(int)(K[2] >> 56) ] ^
C1[(int)(K[1] >> 48) & 0xff] ^
C2[(int)(K[0] >> 40) & 0xff] ^
C3[(int)(K[7] >> 32) & 0xff] ^
C4[(int)(K[6] >> 24) & 0xff] ^
C5[(int)(K[5] >> 16) & 0xff] ^
C6[(int)(K[4] >> 8) & 0xff] ^
C7[(int)(K[3] ) & 0xff];
L[3] = C0[(int)(K[3] >> 56) ] ^
C1[(int)(K[2] >> 48) & 0xff] ^
C2[(int)(K[1] >> 40) & 0xff] ^
C3[(int)(K[0] >> 32) & 0xff] ^
C4[(int)(K[7] >> 24) & 0xff] ^
C5[(int)(K[6] >> 16) & 0xff] ^
C6[(int)(K[5] >> 8) & 0xff] ^
C7[(int)(K[4] ) & 0xff];
L[4] = C0[(int)(K[4] >> 56) ] ^
C1[(int)(K[3] >> 48) & 0xff] ^
C2[(int)(K[2] >> 40) & 0xff] ^
C3[(int)(K[1] >> 32) & 0xff] ^
C4[(int)(K[0] >> 24) & 0xff] ^
C5[(int)(K[7] >> 16) & 0xff] ^
C6[(int)(K[6] >> 8) & 0xff] ^
C7[(int)(K[5] ) & 0xff];
L[5] = C0[(int)(K[5] >> 56) ] ^
C1[(int)(K[4] >> 48) & 0xff] ^
C2[(int)(K[3] >> 40) & 0xff] ^
C3[(int)(K[2] >> 32) & 0xff] ^
C4[(int)(K[1] >> 24) & 0xff] ^
C5[(int)(K[0] >> 16) & 0xff] ^
C6[(int)(K[7] >> 8) & 0xff] ^
C7[(int)(K[6] ) & 0xff];
L[6] = C0[(int)(K[6] >> 56) ] ^
C1[(int)(K[5] >> 48) & 0xff] ^
C2[(int)(K[4] >> 40) & 0xff] ^
C3[(int)(K[3] >> 32) & 0xff] ^
C4[(int)(K[2] >> 24) & 0xff] ^
C5[(int)(K[1] >> 16) & 0xff] ^
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
On Wed, 20 Apr 2005, Daniel Jacobowitz stipulated:
> On Wed, Apr 20, 2005 at 08:16:22PM +0100, Nix wrote:
>> On 14 Apr 2005, John David Anglin spake:
>> >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
>> >
>> > You need to increase the application limits for data on your system.
>>
>> No, something is very wrong here, I think. genattrtab has allocated
>> *4Gb*!
[snip]
> Note that that's a total allocation, not a peak allocation. The 4GB
> total isn't unlikely, with all the PPC DFAs.
Oh, right: I misread this as an OS-sourced message, not the one from
xmalloc(). Sorry for the misinformation.
Getting useful information out of this has just become practical.
Good. :)
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
