Abt definition for structure tree
Hello all, Can anyone tell me where i can find the definition of tree. One structure is typedef-ed to tree. But i cant find that structure. I have been hunting it for sometime. Can some one help me. Thanks in advance. Regards, Shafi
Re: Including GMP/MPFR in GCC repository?
On Wed, Oct 11, 2006 at 11:19:26PM -0400, Kaveh R. GHAZI wrote: > > On Mon, 9 Oct 2006, Mark Mitchell wrote: > > > Kaveh R. GHAZI wrote: > > > Has there been any thought to including GMP/MPFR in the GCC repository > > > like we do for zlib and intl? > > > > I do not think we should be including more such packages in the GCC > > repository. It's complicated from an FSF perspective and it bloats our > > software. GCC is a complicated piece of software, and to build it you > > need a lot of stuff installed on your system. I think we should just > > accept that. :-) > > So when I start using MPFR from the middle-end for PR 29335, it's okay to > force everyone building GCC to get MPFR? (I.e. not just the people who > want to build fortran.) > > If so, that makes my life much easier and I'm all for it. Including MPFR > was my way to smooth things over with this new dependency. I'm happy not > to have to do it. :-) > Kaveh, It should be straight forward to modify the current configure tests in toplevel for the versions of gmp and mpfr you need. I would recommend at least mpfr 2.2.0 (which would allow me to kill the ugly hacks in gfortran). For gmp, you may be able to use a version as old as 4.1.0. -- Steve
Re: Including GMP/MPFR in GCC repository?
On Wed, 11 Oct 2006, Mark Mitchell wrote: > Kaveh R. GHAZI wrote: > > On Mon, 9 Oct 2006, Mark Mitchell wrote: > > > >> Kaveh R. GHAZI wrote: > >>> Has there been any thought to including GMP/MPFR in the GCC repository > >>> like we do for zlib and intl? > >> I do not think we should be including more such packages in the GCC > >> repository. It's complicated from an FSF perspective and it bloats our > >> software. GCC is a complicated piece of software, and to build it you > >> need a lot of stuff installed on your system. I think we should just > >> accept that. :-) > > > > So when I start using MPFR from the middle-end for PR 29335, it's okay to > > force everyone building GCC to get MPFR? (I.e. not just the people who > > want to build fortran.) > > It is my opinion (as a GCC developer, not as a representative of the > FSF/SC) that, yes, that is fine. I think most other people that > responded agreed. (I do think that we should make sure that MPFR works > on all of the popular host platforms, of course.) Terrific! Cross-referencing the gcc-testresults list with the proposed list of primary and secondary platforms here: http://gcc.gnu.org/ml/gcc/2006-10/msg00016.html I see the following platforms are providing gfortran test results, which implies that they have MPFR. In a couple of cases I wasn't able to find a direct target match, so I used a similar platform and noted that in parentheses next to the desired platform triplet. We can also check the list of known platforms supporting MPFR from their website for additional safety. In there is claims to support i386-unknown-freebsd5.4 and hppa2.0w-hp-hpux11.23 so those fuzzy matches below are cleared. I don't know about mipsisa64-elf, but I suspect it works given that other mips do (irix, linux-gnu). Codesourcery provides nightly arm-eabi results without fortran. Perhaps you can check that one? http://www.mpfr.org/mpfr-current/ Is this sufficient research to proceed in your opinion? Thanks, --Kaveh Primary Platforms - * arm-eabi (arm-unknown-linux-gnu) http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg01298.html * i386-unknown-freebsd (alpha-unknown-freebsd5.4) http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01072.html * i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00545.html * i686-apple-darwin http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00583.html * mipsisa64-elf (mipsel-unknown-linux-gnu) http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00638.html * powerpc64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg01317.html * sparc-sun-solaris2.10 http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01273.html * x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01261.html Secondary Platforms --- * hppa2.0w-hp-hpux11.23 (hppa2.0w-hp-hpux11.11) http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01538.html * powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg02076.html * powerpc-apple-darwin http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01076.html * i686-pc-cygwin http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00915.html * i686-mingw32 http://gcc.gnu.org/ml/gcc-testresults/2004-09/msg01087.html * ia64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01826.html
on removal of line number notes at the end of BBs
Hi, Jan,
The patch at http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00399.html
added code to remove line number notes from the end of basic blocks
after say turning a jump at the end of a basic block into a
fallthrough edge.
This unfortunately causes line number info from becoming incorrect for
test programs such as:
int x;
int f() {
x = 0;
while(1);
}
We get line number notes for code only up to "x = 0;".
The line number note for the empty infinite loop is dropped when the
back-edge is turned into a fallthrough edge (?!?). Even if I arrange
for the edge from a block to itself to never be regarded as a
fallthrough edge (it doesn't seem to make sense to me), loop2 still
splits the back-edge such that the loop has separate header and latch
blocks, and at the time of the split, we use the same
try_to_redirect_by_replacing_jump() function and thus lose debug info.
Although I'll be the first to admit that this particular case is not
that useful, it has surprised people on the Frysk project (see
Sourceware bug 3259, for example).
I'm not sufficiently familiar with the code nor do I see a rationale
as to why keeping the notes might change the generated code, even
though I can imagine it might have to do with a loop becoming empty or
some such.
I've considered arranging for such notes to be moved to the
destination of the edge, but in this case the note would still remain
alone in the basic block, and therefore at its end, causing whatever
failure mode it is that got you to add that chunk of code.
I've also considered adding some nop after the source line number
instead of removing, but then I realized that it wouldn't address the
potential problem of generating different code for -g and -g0.
I don't see any such note-removal code in tidy_fallthru_edge(), from
which you claim to have got inspiration, so I wonder if you still
remember what kind of failure modes you envisioned, and whether it
would make sense to come up with some other means to avoid dropping
such line number notes entirely, such as storing
line-number-at-the-end information in basic blocks, or something
similar for loops, and get such notes re-inserted at some convenient
time, such as when re-inserting jumps for fallthru edges that couldn't
be satisfied without a jump, or some such.
Any other ideas?
Thanks in advance,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin Americahttp://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Question about strange register calling truncates to SImode on x86_64
Hello Andrew,
> -mcmodel=small'
> Generate code for the small code model: the program and its
> symbols must be linked in the lower 2 GB of the address space.
> Pointers are 64 bits. Programs can be statically or dynamically
> linked. This is the default code model.
You are right, the documentation I read, too. But as described even for
the small-model pointers are 64-bit and are treated beside the argument
passing via register correctly. The problem is that a function just set
the lower 32-bit of the register, but the method using this register as
argument uses the 64-bit register variant, which means the upper 32-bit of
the register have random values..
E.g: The c code
int foo(const char *h,int n) { n+=(int) *h; return n; }
int doo(int n) { return foo("abc ",n); }
Leads to the assembly on x86_64 (small)
.file "test.c"
.text
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
LFB2:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
movq%rcx, -8(%rbp)
movl%edx, -12(%rbp)
movq-8(%rbp), %rax
movzbl (%rax), %eax
movsbl %al,%eax
addl%eax, -12(%rbp)
movl-12(%rbp), %eax
leave
ret
LFE2:
.section .rdata,"dr"
LC0:
.ascii "abc \0"
.text
.globl _doo
.def_doo; .scl2; .type 32; .endef
_doo:
LFB3:
pushq %rbp
LCFI2:
movq%rsp, %rbp
LCFI3:
subq$8, %rsp
LCFI4:
movl%ecx, -4(%rbp)
movl-4(%rbp), %edx
movl$LC0, %ecx
call_foo
leave
ret
...
You see, that function "doo" passes the symbolRef LC0 via ecx to function
foo. But function "foo" uses as input argument rcx for the pointer.
I think the definition of in i386.md is the reason for this incorrect
behaviour. I sent a small patch which seems to solve this problem quite
well without side-effect.
Regards,
i.A. Kai Tietz
--- gcc-4-2-20060930_org/gcc-4.2-20060930/gcc/config/i386/i386.md
2006-09-07 19:53:18.0 +0200
+++ gcc-4.2-20060930/gcc/config/i386/i386.md2006-10-11
09:44:36.610866100 +0200
@@ -2008,9 +2008,7 @@
return "lea{q}\t{%a1, %0|%0, %a1}";
default:
gcc_assert (!flag_pic || LEGITIMATE_PIC_OPERAND_P (operands[1]));
- if (get_attr_mode (insn) == MODE_SI)
- return "mov{l}\t{%k1, %k0|%k0, %k1}";
- else if (which_alternative == 2)
+ if (which_alternative == 2)
return "movabs{q}\t{%1, %0|%0, %1}";
else
return "mov{q}\t{%1, %0|%0, %1}";
Re: multilib libffi/libjava
Jack Howarth writes: > What is the situation with multilib builds of libffi and > libjava in gcc 4.2 on architectures like x86_64 and ppc64 linux? It works fine. > I ask because I noticed that Fedora's gcc 4.1.1 specfile explicitly > disables the multilib builds in libjava and doesn't seem to package > libffi. Thanks in advance for any clarification on the situation > with that. I thought I would be able to look at x86_64 and ppc64 > linux for examples of how libffi and libjava was properly built as > multilib but it doesn't look like that support is in place yet. It works fine. Try it; building with multilib is the default for gcc. Andrew.
Re: on removal of line number notes at the end of BBs
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> The patch at http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00399.html
> added code to remove line number notes from the end of basic blocks
> after say turning a jump at the end of a basic block into a
> fallthrough edge.
>
> This unfortunately causes line number info from becoming incorrect for
> test programs such as:
>
> int x;
> int f() {
> x = 0;
> while(1);
> }
>
> We get line number notes for code only up to "x = 0;".
I assume this is only a problem when not optimizing.
Without looking at the code, the problem looks quite similar to one I
fixed here:
2005-07-18 Ian Lance Taylor
PR middle-end/22057
* tree-cfgcleanup.c (cleanup_tree_cfg): Only remove forwarder
blocks when optimizing.
Ian
java method calls and GIMPLE
Hi, I've come to a bit of an impasse in the (java) escape analysis. In order to do interprocedural analysis effectively, I need to know what methods are called. However, it is rarely the case that this information is available. For example, a call to System.out.println looks like this: out.0 = out; out.1 = (struct *) out.0; D.966 = out.1->vtable; D.967 = D.966 + 124B; D.968 = *D.967; D.969 = (java.io.PrintStream:: *) D.968; D.970 = _CD_HelloDate[1]; D.971 = (struct *) D.970; D.969 (out.0, D.971); So its all vtables, function lookups and indirect function calls. I appreciate that that's how it works, but its not terribly useful to me, and severely restricts what I can do. Ideally, I would have a list of methods that could be called at a particular polymorphic function call. From there I can do whatever analysis is appropriate. Any ideas how I'd go about this? Thanks Paul PS it seems that even trivial examples, where the type is known at compile time, generate code like this. Perhaps there's scope for a polymorphism removal pass? -- Paul Biggar [EMAIL PROTECTED]
Re: java method calls and GIMPLE
Paul Biggar writes: > I've come to a bit of an impasse in the (java) escape analysis. In > order to do interprocedural analysis effectively, I need to know what > methods are called. However, it is rarely the case that this > information is available. For example, a call to System.out.println > looks like this: > > out.0 = out; > out.1 = (struct *) out.0; > D.966 = out.1->vtable; > D.967 = D.966 + 124B; > D.968 = *D.967; > D.969 = (java.io.PrintStream:: *) D.968; > D.970 = _CD_HelloDate[1]; > D.971 = (struct *) D.970; > D.969 (out.0, D.971); > > So its all vtables, function lookups and indirect function calls. I > appreciate that that's how it works, but its not terribly useful to > me, and severely restricts what I can do. > > Ideally, I would have a list of methods that could be called at a > particular polymorphic function call. From there I can do whatever > analysis is appropriate. > > Any ideas how I'd go about this? Yes. You'll need to represent virtual function calls at the GIMPLE level, or to keep track of which calls are associated with which methods. This is key to getting IPA to work. It should be fairly easy, given a class and a vtable offset, to find the method. This will require a callback into the front end. Andrew.
Re: java method calls and GIMPLE
> "Paul" == Paul Biggar <[EMAIL PROTECTED]> writes: Paul> I've come to a bit of an impasse in the (java) escape analysis. In Paul> order to do interprocedural analysis effectively, I need to know what Paul> methods are called. Paul> So its all vtables, function lookups and indirect function calls. I Paul> appreciate that that's how it works, but its not terribly useful to Paul> me, and severely restricts what I can do. Paul> Ideally, I would have a list of methods that could be called at a Paul> particular polymorphic function call. From there I can do whatever Paul> analysis is appropriate. Paul> Any ideas how I'd go about this? You'll find it difficult to make a list of all methods that could be called, because java allows runtime creation of new classes. You would have to assume that the world is closed -- which is pretty unusual for (non-embedded) java code. You probably know this already :) Paul> PS it seems that even trivial examples, where the type is known at Paul> compile time, generate code like this. Perhaps there's scope for a Paul> polymorphism removal pass? Yes, I have a java-specific devirtualization patch sitting here. It can devirtualize and also lower interface dispatch to virtual dispatch. This patch needs some work before it could go in. You might be interested in the part of the patch that adds OBJ_TYPE_REF wrappers to the generated trees. This makes it much simpler to go from a low-level CALL_EXPR (using offsets from the vtable or whatnot) back to the decl for the called method. See the patch attached here: http://gcc.gnu.org/ml/java/2006-08/msg00020.html The only reason I didn't commit the OBJ_TYPE_REF code yet is that I wasn't sure that my choice for the OBJ_TYPE_REF_TOKEN value was the best one. Tom
Re: java method calls and GIMPLE
Andrew Haley <[EMAIL PROTECTED]> writes: > Yes. You'll need to represent virtual function calls at the GIMPLE > level, or to keep track of which calls are associated with which > methods. This is key to getting IPA to work. > > It should be fairly easy, given a class and a vtable offset, to find > the method. This will require a callback into the front end. But note that IPA via LTO is not going to permit callbacks into the front end, because there isn't going to be a front end. So the information needs to be represented in GIMPLE somewhere. Ian
Re: Question about strange register calling truncates to SImode on x86_64
Hi, On Wed, 11 Oct 2006, Kai Tietz wrote: > > -mcmodel=small' > > Generate code for the small code model: the program and its > > symbols must be linked in the lower 2 GB of the address space. > > Pointers are 64 bits. Programs can be statically or dynamically > > linked. This is the default code model. > > You are right, the documentation I read, too. But as described even for > the small-model pointers are 64-bit and are treated beside the argument > passing via register correctly. The problem is that a function just set > the lower 32-bit of the register, but the method using this register as > argument uses the 64-bit register variant, which means the upper 32-bit of > the register have random values.. No. The x86-64 instructions which set a 32bit register implicitely zero out the upper 32bit. This is in difference to those operating on the 16 or 8bit parts, which leave the upper parts untouched. So this code actually sets $rcx to [0, (uint32)&.LC0] As you are compiling for the small model it's required that &.LC0 == (uint32)&.LC0, because it's static data. And yes, this means that small code model executables have to have a base address < 2GB. This is in difference to the small PIC model, where the overall range of all static program addresses must be < 2GB. Ciao, Michael.
Re: java method calls and GIMPLE
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Yes. You'll need to represent virtual function calls at the GIMPLE > > level, or to keep track of which calls are associated with which > > methods. This is key to getting IPA to work. > > > > It should be fairly easy, given a class and a vtable offset, to find > > the method. This will require a callback into the front end. > > But note that IPA via LTO is not going to permit callbacks into the > front end, because there isn't going to be a front end. So the > information needs to be represented in GIMPLE somewhere. I understand, but (IIRC) every time this has come up there has been some disagreement: I remember it being said that GIMPLE wasn't supposed to represent abstractions such as virtual methods. I may be misremembering! Anyway, a front end callback is surely good enought for a proof of concept. Andrew.
Re: java method calls and GIMPLE
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> But note that IPA via LTO is not going to permit callbacks into the Ian> front end, because there isn't going to be a front end. So the Ian> information needs to be represented in GIMPLE somewhere. Unfortunately there are lots of unsolved problems here, namely what the type system will look like. My current devirtualization pass relies on facts about the java type system in order to do its work. And unless I'm mistaken there are even simpler LTO problems that remain unsolved -- e.g., gcj sets flag_wrapv, but it seems to me that this would have to be a flag on operations rather than a global for LTO to be truly language independent. Tom
Re: java method calls and GIMPLE
Andrew> Anyway, a front end callback is surely good enought for a proof of Andrew> concept. OBJ_TYPE_REF exists, is GIMPLE, and we already have a patch to add it to gcj. Tom
Re: java method calls and GIMPLE
On Wed, Oct 11, 2006 at 11:12:52AM -0600, Tom Tromey wrote: > > "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ian> But note that IPA via LTO is not going to permit callbacks into the > Ian> front end, because there isn't going to be a front end. So the > Ian> information needs to be represented in GIMPLE somewhere. > > Unfortunately there are lots of unsolved problems here, namely what > the type system will look like. My current devirtualization pass > relies on facts about the java type system in order to do its work. It seems that there should be commonalities that can be exploited; the rules for doing devirtualization in C++ are pretty close to those used for Java (though each language has relevant features the other lacks, like the Java "final" keyword).
Re: java method calls and GIMPLE
Tom Tromey wrote: "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> But note that IPA via LTO is not going to permit callbacks into the Ian> front end, because there isn't going to be a front end. So the Ian> information needs to be represented in GIMPLE somewhere. Unfortunately there are lots of unsolved problems here, namely what the type system will look like. My current devirtualization pass relies on facts about the java type system in order to do its work. To make LTO work, we're going to want to understand what facts you need, and then get them passed on to LTO. If we can get a GIMPLE pass that can do what we need, then we're most of the way there. And unless I'm mistaken there are even simpler LTO problems that remain unsolved -- e.g., gcj sets flag_wrapv, but it seems to me that this would have to be a flag on operations rather than a global for LTO to be truly language independent. Sure, we've got to fix that. Want to help? :-) No question there's a long row to hoe, here. I would hope that we could start with a devirtualization pass on GIMPLE, using langhooks if necessary, and gradually migrate that to work with LTO. I certainly wouldn't argue that we should wait for LTO to be done to tackle devirtualization. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
building gcc
Hi, I'd like to build gcc with just the C/C++ front ends. Are there any configure options I could use to make only a minimum gcc build to get those 2 languages working? Also, I'd like to be able to debug gcc. Is there any special flags for this? Finally, once it's built, I'd like to manually traverse the AST. Any pointers on where this would be? Thanks, Bob Rossi
Re: building gcc
Bob Rossi wrote: Hi, I'd like to build gcc with just the C/C++ front ends. Are there any configure options I could use to make only a minimum gcc build to get those 2 languages working? Take a look at the Fine documentation that is available at http://gcc.gnu.org In particular looking at the installation documentation where it describes the --enable-languages=c,c++ configure option would be useful. The answers to your other questions can be found in the documents and WIKI at gcc.gnu.org. Also, I'd like to be able to debug gcc. Is there any special flags for this? Finally, once it's built, I'd like to manually traverse the AST. Any pointers on where this would be? Thanks, Bob Rossi
Re: dereferencing type-punned pointer will break strict-aliasing rules
> "Jack" == Jack Howarth <[EMAIL PROTECTED]> writes: Jack> Has anyone noticed that we are breaking the strict-aliasing ruls in Jack> natVMVirtualMachine.cc? Jack> Does this merit a bug report or how else should it be handled? Please file a bug report. Or fix it if you prefer :-) Tom
Re: building gcc
On Wed, Oct 11, 2006 at 02:39:39PM -0700, David Daney wrote: > Bob Rossi wrote: > >Hi, > > > >I'd like to build gcc with just the C/C++ front ends. Are there > >any configure options I could use to make only a minimum gcc > >build to get those 2 languages working? > > Take a look at the Fine documentation that is available at > http://gcc.gnu.org Yes, thanks. > In particular looking at the installation documentation where it > describes the --enable-languages=c,c++ configure option would be useful. Thank you, this is what I was looking for. > The answers to your other questions can be found in the documents and > WIKI at gcc.gnu.org. In particular, I was just wondering how do compile GCC with debug. Not how to debug it. I tried CFLAGS="-g" ./configure ..., but it still compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure trick that will help get me ready to debug gcc, please let me know. Thanks, Bob Rossi
Re: building gcc
On Oct 11, 2006, at 6:27 PM, Bob Rossi wrote: In particular, I was just wondering how do compile GCC with debug. developers cd gcc && make. :-) Gotta love magic. If you've built it already, make clean && make.
Re: aligned attribute and the new operator (pr/15795)
* Ian Lance Taylor <[EMAIL PROTECTED]> [2006-10-10 10:15]: > [EMAIL PROTECTED] writes: > > > - the default versions of operator new and the aligned version of > > operator new should be defined in the same section. That way, > > when a user overrides the default operator new, they will get > > a link error (duplicate definitions of new) unless they also > > define the aligned version of operator new. > > That would be a bad idea since it would break standard conformant > programs which only override the default operator new. Ahh, right. Regardless, I've realized this technique won't work anyway. No error would be given when the implementation of operator new is declared weak, which is common enough. There are some other possibilities, none of them perfect, like a command line option, or teaching the linker something about operator new. > You are implicitly assuming that we know the alignment of memory > returned by new. If we know that, then whenever we need aligned > memory, we can ask for a bit more memory and force the alignment. > That will always work and avoids the concerns of overriding new. We > can generate more optimal code by providing a command line option > which specifies the alignment of memory returned by new. I think I'm assuming the same thing GCC already assumes about new. I don't see any thing in GCC that attempts to align the result of a call to operator new. For some targets it doesn't matter, for example, when load and store instructions work on unaligned addresses, but pr/15795 points out a case where this doesn't work. Forcing the alignment of the result of new isn't going to work because we have no way to reconstruct the correct address when calling delete. We could save the correct address at the beginning of the memory returned, but that is an ABI change. If we are willing to consider an ABI change, I think an approach that allows new to call some form of memalign would be better than having the compiler force alignment after calling new. Are we open to making an ABI change? For now, I will still promote the original idea of having a second version of new with an alignment argument. And require a command line option to emit calls to the aligned version of the default new operator. Is a command line option sufficient? Trevor
Re: Including GMP/MPFR in GCC repository?
On Mon, 9 Oct 2006, Mark Mitchell wrote: > Kaveh R. GHAZI wrote: > > Has there been any thought to including GMP/MPFR in the GCC repository > > like we do for zlib and intl? > > I do not think we should be including more such packages in the GCC > repository. It's complicated from an FSF perspective and it bloats our > software. GCC is a complicated piece of software, and to build it you > need a lot of stuff installed on your system. I think we should just > accept that. :-) So when I start using MPFR from the middle-end for PR 29335, it's okay to force everyone building GCC to get MPFR? (I.e. not just the people who want to build fortran.) If so, that makes my life much easier and I'm all for it. Including MPFR was my way to smooth things over with this new dependency. I'm happy not to have to do it. :-) Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Including GMP/MPFR in GCC repository?
Kaveh R. GHAZI wrote: On Mon, 9 Oct 2006, Mark Mitchell wrote: Kaveh R. GHAZI wrote: Has there been any thought to including GMP/MPFR in the GCC repository like we do for zlib and intl? I do not think we should be including more such packages in the GCC repository. It's complicated from an FSF perspective and it bloats our software. GCC is a complicated piece of software, and to build it you need a lot of stuff installed on your system. I think we should just accept that. :-) So when I start using MPFR from the middle-end for PR 29335, it's okay to force everyone building GCC to get MPFR? (I.e. not just the people who want to build fortran.) It is my opinion (as a GCC developer, not as a representative of the FSF/SC) that, yes, that is fine. I think most other people that responded agreed. (I do think that we should make sure that MPFR works on all of the popular host platforms, of course.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: on removal of line number notes at the end of BBs
On Oct 11, 2006, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> int x; int f() { x = 0;
>> while(1); }
>> We get line number notes for code only up to "x = 0;".
> I assume this is only a problem when not optimizing.
The opposite, actually. It's optimization that breaks it.
Of course optimization can change stuff and debug info sometimes is
lost, but in this case we *do* have code for that loop, so we might as
well try to preserve the line number info somehow. We shouldn't drop
it just because we turn annotated-with-line-numbers jumps into
fallthru edges that later have to be re-emitted without line numbers.
> Without looking at the code, the problem looks quite similar to one I
> fixed here:
It is similar, indeed, but this removal takes place in RTL.
Thanks for the pointer,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin Americahttp://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
