Re: executable stack in gcc shared libs?
Paweł Sikora wrote: > Hi all, > > I noticed (readelf -lW/grep) that some gcc libraries require executable stack: > > /usr/lib64/libffi.so.4.0.1 GNU_STACK 0x00 0x >0x 0x00 0x00 RWE 0x8 > /usr/lib64/libgcj.so.8.0.0 GNU_STACK 0x00 0x >0x 0x00 0x00 RWE 0x8 > /usr/lib64/libgmp.so.3.4.2 GNU_STACK 0x00 0x >0x 0x00 0x00 RWE 0x8 > > Is this expected marking or just missed `-z noexecstack` for assembly parts? I don't know for sure about libgmp, but the others don't need execstack. Andrew.
Re: executable stack in gcc shared libs?
21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: >I don't know for sure about libgmp, but the others don't need execstack. hmm, looks like PR libffi/28036.
Re: executable stack in gcc shared libs?
[EMAIL PROTECTED] wrote: > 21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: > >> I don't know for sure about libgmp, but the others don't need execstack. > > hmm, looks like PR libffi/28036. How would this affect libgmp? Andrew.
Re: executable stack in gcc shared libs?
21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: >[EMAIL PROTECTED] wrote: >> 21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: >> >>> I don't know for sure about libgmp, but the others don't need execstack. >> >> hmm, looks like PR libffi/28036. > >How would this affect libgmp? proviously listed libgmp is a copy-paste bug, but i'm wondering why libffi wasn't fixed since 4.1 release?
Re: executable stack in gcc shared libs?
[EMAIL PROTECTED] wrote: > 21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: > >> [EMAIL PROTECTED] wrote: >>> 21/3/2008, "Andrew Haley" <[EMAIL PROTECTED]> napisał/a: >>> I don't know for sure about libgmp, but the others don't need execstack. >>> hmm, looks like PR libffi/28036. >> How would this affect libgmp? > > proviously listed libgmp is a copy-paste bug, > but i'm wondering why libffi wasn't fixed since 4.1 release? Because no-one did it. It's simple enough to do and doesn't require approval from all the back-ed maintainers individually. In http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00949.html Andrew Pinski asked a question that was never answered. If doko would answer that question, the patch could be committed. Andrew.
Re: Different *CFLAGS in gcc/Makefile.in
## the C flags (without any gcc -I...stuff) to be included in ## compilation of MELT generated C code thru the melt-cc-script ## do not put $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) ##there! MELT_CFLAGS= $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS) But I'm not sure of the T_CFLAGS (it probably is related to target specific stuff only). T_CFLAGS is flags that the *target* decides to add. It's actually used only by ia64/t-hpux and gcc.c, and getting rid of it in some way would be a good thing. I think you're okay with your choice. Paolo
What licence(s) does GNAT and the runtime fall under now?
Hi, I was just wondering what licences are used for GNAT now that AdaCore has GNAT-GPL rather than GNAT with GMGPL'd runtime. It seems that the source - when I last looked - for the runtime was GPL rather that GMGPL, but I thought that only the FSF could change the licence of these files? Can somebody please explain what licences are used for GCC-4.3.x & GNAT? Thanks, Luke.
Re: What licence(s) does GNAT and the runtime fall under now?
Luke A. Guest wrote: Hi, I was just wondering what licences are used for GNAT now that AdaCore has GNAT-GPL rather than GNAT with GMGPL'd runtime. It seems that the source - when I last looked - for the runtime was GPL rather that GMGPL You were not looking at the sources from the FSF , but I thought that only the FSF could change the licence of these files? The license for the run-time sources at the FSF is the GMGPL. Can somebody please explain what licences are used for GCC-4.3.x & GNAT?
Re: What licence(s) does GNAT and the runtime fall under now?
On Fri, 2008-03-21 at 14:20 -0400, Robert Dewar wrote: > Luke A. Guest wrote: > The license for the run-time sources at the FSF is the GMGPL. > > > > Can somebody please explain what licences are used for GCC-4.3.x & GNAT? Good to know, thanks. Luke.
gcc-4.4-20080321 is now available
Snapshot gcc-4.4-20080321 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080321/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 133439 You'll find: gcc-4.4-20080321.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080321.tar.bz2 C front end and core compiler gcc-ada-4.4-20080321.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080321.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080321.tar.bz2 C++ front end and runtime gcc-java-4.4-20080321.tar.bz2 Java front end and runtime gcc-objc-4.4-20080321.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080321.tar.bz2The GCC testsuite Diffs from 4.4-20080314 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
How should _Decimal64 and _Decimal128 be aligned on stack?
When passing _Decimal64 or _Decimal128 to a function via stack, how should they be aligned? Currently, gcc aligns them at 4byte boundary. Is this desirable? H.J.
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
On Fri, Mar 21, 2008 at 5:29 PM, H.J. <[EMAIL PROTECTED]> wrote: > When passing _Decimal64 or _Decimal128 to a function via stack, how > should they be aligned? Currently, gcc aligns them at 4byte boundary. > Is this desirable? Shouldn't it always be 4 byte aligned because the SysV ABI only talks about word alignment? Thanks, Andrew Pinski
Re: Is vec_init allowed to FAIL?
Jan Hoogerbrugge wrote: I see however that no code is generated if trimedia_expand_vector_init() returns 0 and the define_expand FAILs. I also see in other targets that a vec_init always ends with a DONE. Could it be that vec_init is not allowed to FAIL? Grep for "vec_init", and we see that it is used in expr.c, store_constructor(), case VECTOR_TYPE. It calls optab_handler to set icode, and then at the end calls GEN_FCN (icode). There is no provision for the GEN_FCN (icode) call returning failure, so yes, vec_init is not allowed to fail. This could probably be fixed with a little code rearrangement. For instance, you could try putting all code starting with the line that tests "need_to_clear && size > 0 && !vector" into a loop that iterates twice. If vector is not set, then we exit the loop after emitting code. If vector is set, and the GEN_FCN call succeeded, then we exit the loop. If vector is set, and the GEN_FCN call fails, then we clear vector, throw away any RTL that may have been emitted, and loop back for a second pass using the non-vector code, which always succeeds. Throwing away the temporary RTL can be accomplished by using start_sequence and end_sequence. There may also be other ways to fix this. Jim
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
On Fri, Mar 21, 2008 at 5:37 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Fri, Mar 21, 2008 at 5:29 PM, H.J. <[EMAIL PROTECTED]> wrote: > > When passing _Decimal64 or _Decimal128 to a function via stack, how > > should they be aligned? Currently, gcc aligns them at 4byte boundary. > > Is this desirable? > > Shouldn't it always be 4 byte aligned because the SysV ABI only talks > about word alignment? > DFP is beyond i386 psABI. Gcc aligns _Decimal32 to 4 byte, _Decimal64 to 8 bytes and _Decimal128 to 16bytes. The question is what is the best alignment for them when passing to a functions. H.J.
