Re: GCC-4.1.x include/ssl/*.h ??

Mark Mitchell wrote: My current expectation is that I will apply your patch, test locally, but not produce an RC3. I built a native compiler with the patch. I The ssp include files ended up in $prefix/lib/include/ssp. There are no other files in $prefix/lib/include. The C++ header files

Re: GCC-4.1.x include/ssl/*.h ??

Mark Mitchell wrote: Joseph thinks these should go in $libsubdir; I'm going to try that now. With much help from Daniel and Joseph, I have a patch for this problem, which I am now testing. This will be the final patch for GCC 4.1.0. I plan to work through the release checklist tonight

Re: 4.1.0-RC{1,2} installs headers to /include

that the headers end up in $prefix/include/c++ for me. The SSP patch I applied yesterday will have no affect on this situation, as it applied only to the libssp headers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 4.1.0-RC{1,2} installs headers to /include

René Rebe wrote: Hi, On Tuesday 28 February 2006 19:50, Mark Mitchell wrote: René Rebe wrote: Hi all, in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include directory: Are you sure? The log you show is presumably from your build log; have you verified that this is where

GCC 4.1.0 Released

to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 4.1.0-RC{1,2} installs headers to /include

René Rebe wrote: As expected the headers are in the correct location now. Good. Have you filed a bug in Bugzilla about this issue? If not, would you care to do so? To do so, please visit gcc.gnu.org, and look for the link on the left side of the page. Thanks, -- Mark Mitchell CodeSourcery

GCC 4.1 branch open

The GCC 4.1 branch is now open, under the usual branch rules: fixes for regressions only. Remember: the GCC 4.0 branch will freeze at midnight tonight, GMT-8, in preparation for GCC 4.0.3. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.0 Released

what I believe is the right thing. But, I will also be sensitive to the developer community's desire for predictability of decision-making. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.0 Released

value in precisely such ways!) but it's better to be safe than sorry, and I didn't have the resources to verify exactly which versions might or might not work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.0 Released

on the mainline. I have not myself verified the claim, but there has been a suggestion that there is at least one open regression due to the patch. If there are any known regressions from the patch, it's certainly not eligible for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

Re: GCC 4.1.0 Released

, users have been expected to specify their target CPU in order to get good performance. It's swell that GCC 4.2 will work better by default on IA32, but that's not a compelling argument for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC-4.1.x include/ssl/*.h ??

there's a problem in there somewhere. I never run make install in parallel because, frankly, it's *never* worked for me; I just thought all of our makefiles were generally broken for parallel installation. :-( -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.0 Released

Roman Belenov wrote: David Edelsohn [EMAIL PROTECTED] writes: Upgrading GNU tar to 1.15.1 fixed the problem for me. So what is the actual requirement - 1.14 or 1.14 or above ? The latter. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.0.3 RC1

tarballs on the FTP site. The modified release script has not been checked in, but will be shortly. Assuming that there are no major problems, I expect the final release in the middle part of next work. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.0.3 RC1

show an improvement on SH4, please go ahead and check them in. Please inform me of the status ASAP. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.0.3 release

I am not aware of any showstoppers for the 4.0.3 release. Therefore, I plan to spin the release tomorrow evening, GMT - 8. Speak now or forever hold your peace! :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Problem with pex-win32.c

, and, indeed that avoids the DOS windows popping up in Cygwin -- but they you get no output at all under Windows. I guess I have two questions: (a) do you feel like fixing this, and (b) if not, do you have any objection to using CreateProcess? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: Problem with pex-win32.c

Ross Ridge wrote: Mark Mitchell wrote: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things

Re: Problem with pex-win32.c

: No output from child. parent std: Works. DOS Console === parent spawn: Works. parent nostd: No output from child. parent std: No output from child. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 #include stdio.h #include process.h #include string.h #include

GCC 4.0.3 Released

, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

GCC 4.0 branch open

The GCC 4.0 branch is now open, under the usual release-branch rules. However, I do not plan to make any further releases from the 4.0 branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc-4.2-20060304 is now available

= 3606941 I'd really suggest to make this part of gcc-objc instead of adding another one. Definitely. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc-4.2-20060304 is now available

is 80% of the total. Why not simplify things a bit and just package it all up together? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.0.3 Released

be http://gcc.gnu.org/gcc-4.0 instead. Fixed with the obvious patch. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.0.3 Released

? Now corrected, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

, avoiding the bug seems clearly desirable. CodeSourcery will fix this on our branches, and contribute the patch; hopefully we can work something out that will make the libiberty maintainers happy. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

. What cygcheck output would be helpful? I've never run cygcheck until just now, and it seems to have lots of options. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

Mark Mitchell wrote: What cygcheck output would be helpful? I've never run cygcheck until just now, and it seems to have lots of options. By the way, I don't see any reason to suspect that there's a Cygwin bug. The situation is: 1. A Cygwin xterm does not have an associated console. 2. You

Re: Problem with pex-win32.c

Here is a sample program which does the right thing (no spurious console windows, all output visible) when run either from a console or from a console-free environment, such as a Cygwin xterm. This is the code we'll be working into libiberty -- unless someone has a better solution! -- Mark

Re: Problem with pex-win32.c

this into libiberty... :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

can't assume that all users are using either Cygwin or a console, so we still have to handle the case that there is no console available when we want to spawn another program, with that program's standard streams redirected. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

Mark Mitchell wrote: As a test case, I'd recommend the latest code I posted. If a MinGW application tries to open CONOUT$ with CreateFile, it gets INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is available. I should have said in a Cygwin xterm somewhere in that sentence

Re: Problem with pex-win32.c

contained to pex-win32.c. We're just trying to do the right thing by contributing it. It's of course up to the FSF libiberty maintainers (after we get a patch posted, of course) to determine whether or not they want to accept the patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

FSF Policy re. inclusion of source code from other projects in GCC

, and specifically list those files? RMS has given us permission not to set up a separate repository for the STL files. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: FSF Policy re. inclusion of source code from other projects in GCC

Joe Buck wrote: On Fri, Mar 17, 2006 at 01:23:36PM -0800, Mark Mitchell wrote: Richard Guenther wrote: Do I understand this correctly that the upstream GLIBC versions of the files will get their license changed, or will this happen only in the GCC copy? Only in the GCC copy. Maybe we

Re: FSF Policy re. inclusion of source code from other projects in GCC

by removing whatever Makefile bits compile it. My experience is that it usually takes some time for RMS to grant a license exception, and that he may not choose to do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: FSF Policy re. inclusion of source code from other projects in GCC

in this case that the GLIBC maintainers should be willing to accommodate reasonable requests, although obviously reasonableness is in the eye of the beholder. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: FSF Policy re. inclusion of source code from other projects in GCC

, then please gather it and present it to the FSF. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: FSF Policy re. inclusion of source code from other projects in GCC

Mark Mitchell wrote: Benjamin Kosnik wrote: The STL files in libstdc++-v3 need to be clearly marked as not part of GCC. Benjamin, will you please take care of that, by modifying the libstdc++-v3/README to indicate that the files originally from HP are not part of GCC, and specifically list

Re: FSF Policy re. inclusion of source code from other projects in GCC

forty-eight hours, as the outside. I would suggest copying the GCC SC, since as the SC is the official maintainer of GCC, the SC needs to understand the outcome. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: FSF Policy re. inclusion of source code from other projects in GCC

this * software is freely granted, provided that this notice * is preserved. * */ Mark Mitchell wrote: My guess is that it's OK to include the Sun code, since it's in the public domain. This may just be nit-picking, but the above notice

GCC 4.2 Status Report (2006-03-17)

25th. Even after Stage 2 ends, patches submitted before the end of Stage 2 can be applied in Stage 3, until we decide otherwise. So, wrap up those last contributions, submit them, review other people's patches, and then prepare to start fixing bugs for 4.2. Thanks, -- Mark Mitchell

Re: FSF Policy re. inclusion of source code from other projects in GCC

this call, though, and I'm not trying to accuse anyone of anything whatsoever, so please don't interpret that request as some kind of dig. Nor do I in any way fail to appreciate Red Hat's support of free software by donating the machine. So, this is definitely in the my-two-cents category. -- Mark

LLVM copyright?

Chris -- As I just sent in my Gelato abstract (at which you and I will be presenting talks about different approaches to link-time optimization in GCC), I was wondering what the status of the LLVM copyright assignment is. Has there been progress on that front? Thanks, -- Mark Mitchell

Re: GNU Pascal branch

certainly need to be approved by the GCC SC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

players can. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

by the FSF), and then just allow people to post links here, when a new job is posted there, or some such. In that model, I don't know how to solve the enforcement issue, but we could post a policy next to the descriptions of the lists. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

Re: GCC Compiler Engineer job (I am not a recruiter)

suited to gcc-help do not have this same impact. Here, if Company A and Company B both want to recruit, but A adheres to the policy while B does not, A loses. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

direction from Mike and Joe. Mike, Joe, do either of you care to argue the point? If not, I'll volunteer to write some text for the web pages, and ask Gerald to find a place to put it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

outcome here, but if we're moving towards no ads then I'd just suggest we make it an absolute requirement, as that's clearest. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

, as there are real bugs that you're fixing. Please do be careful, and please confine the changes to those that actually fix bugs, rather than just clean-ups for clean-up sake. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Catching up on status reports

I'm behind on two RM duties: bug priorities and status reports. Fortunately, I'm not traveling this week, so I'll get caught up shortly. I just wanted to let everyone know that I'd not forgotten there's stuff to be done... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: GCC Compiler Engineer job (I am not a recruiter)

Gerald Pfeifer wrote: On Mon, 10 Apr 2006, Mark Mitchell wrote: It seems like we're getting consensus around that approach, despite the initial sentiment in the other direction from Mike and Joe. Mike, Joe, do either of you care to argue the point? If not, I'll volunteer to write some text

GCC 4.1 Status Report (2006-04-16)

. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Experimental features in releases

and is not recommended for production use At least we're ensuring that even someone copying someone else's Makefile is aware that they're in dangerous territory. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Experimental features in releases

to me. Good. Independent of this issue, I'd certainly like to get consensus on the general question. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Experimental features in releases

Mark Mitchell wrote: I'm going to send two messages to follow up because I think we've got two different topics. This message is about: In any case, the broader question is: to what extent should we have experimental options in releases, and how should we warn users of their experimental

Re: Vector types and type conversions

? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Vector types and type conversions

of elements as the input vector. I suppose that we could introduce these operators into C as well, although the pseudo-template syntax might not be as natural for C users. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Vector types and type conversions

Joe Buck wrote: On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote: Let's accept that both the bit-preserving and value-preserving conversions would be useful. How do we differentiate the two? In C++, we could invent __value_castT and __bitwise_castT. For example

Re: Vector types and type conversions

Chris Lattner wrote: On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote: Let's accept that both the bit-preserving and value-preserving conversions would be useful. How do we differentiate the two? For vectors, these operators would apply to each element, and then return a vector

GCC 4.2 Status Report (2006-04-19)

a clearer picture of the functionality situation. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Vector types and type conversions

that a C-style cast from one vector type to another be bit-preserving. So, we can't change that (or static_casts, which are the kind of C++ cast that are using to implement this kind of C-style cast) without breaking backwards compatibility. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: What is the expected behavior of attribute nonnull for C++

compatibility to change it, and (b) some of these kinds of attributes could usefully apply to the this pointer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What is the expected behavior of attribute nonnull for C++

to break your program so that it is in fact NULL, but your program already has undefined behavior at that point.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

to either (a) hard-code this choice, or (b) depend on a --enable-* flag. I think it should be considered bad policy to make things work differently for native/cross environments. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Maintainers and new contributions

similar contributions we should clarify that the submitter (or someone else) is willing to be a maintainer, and ask the SC to sign off. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

-term win may come out of it for one party is lost in the long-term loss for the whole project when a configuration behaves differently depending on native/cross/Canadian. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

is unaffected by cross/native/Canadian. (The case statement is what I meant by hard-coded answers.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

-coded case statement, or an autoconf test that doesn't require linking stuff. In my ideal world, we wouldn't set GCC_NO_EXECUTABLES because we'd be able to link by this point, but I guess it must be there to support exactly the kind of environment you're in. -- Mark Mitchell CodeSourcery [EMAIL

Re: libstdc++ in a combined tree

was suggesting. In general, I just want to make sure we don't do things that make cross or Canadian-cross builds behave differently from native compilation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Status of SEE and Autovectorization patches?

reviewed the SEE patches. Is there anything more than needs to be done to get them committed, in your view? Richard, do you think you'll have a chance to look at the autovectorization work soon? If not, is there someone else you might suggest to review it? Thanks, -- Mark Mitchell

Re: Status of SEE and Autovectorization patches?

on these architectures. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Catching up on lists, release status

implicated in some bugs as well, sadly, and I'll be looking at fixing those, too. If you have information that you feel I should know about, even if duplicative of mail to the list, please feel free to send me a private email to make sure that I'm not missing something critical. Thanks, -- Mark

Re: mips: -G0 vs __dso_handle

documentation in docs/tm.texi, of course. I'll pre-approve that change, but I'll also defer to any other maintainer who has a solution they prefer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A question about your patch for PR c++/26534

is mandated by the standard. I believe that, therefore, the correct fix will be to teach convert_like_real to make the appropriate adjustment; I'm testing that now. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.1 Status Report (2006-05-15)

] wrong code, apparently due to bad VR... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: mips: -G0 vs __dso_handle

DJ Delorie wrote: I'll pre-approve that change, but I'll also defer to any other maintainer who has a solution they prefer. How about this one? OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.1 Status Report (2006-05-15)

on the mainline but has not gone on the 4.1 branch yet. Similarly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning

if the compiler has dumped a random variable of asm() output into a section, but we must have solved that for section anchors as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: PATCH: Compile options.c with -fcommon

H. J. Lu wrote: 2006-05-16 H.J. Lu [EMAIL PROTECTED] * Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o. (gcc-options.o): New rule. * optc-gen.awk: Protect variables for gcc-options.o with #ifdef GCC_DRIVER/#endif. OK. -- Mark Mitchell

Re: libgcc-math and the gcc 4.2 release

branching for 4.2 and only on that branch. I think it's better to remove it from mainline, just so that if there are any build issues we catch them before we branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 branch frozen

I am (finally...) starting the 4.1.1 RC1 build. Please do not check in any changes on the 4.1 branch, even if previous approved. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.1 RC1

%20Status together with any comments you might have about the results. If all goes well, we'll do the official release next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Revert patch for MIPS TImode functions for 4.1.1

big a change to make now. Therefore, Roger, would you please revert your patch? Richard, your patch is OK for 4.1.2, after you feel the mainline version has proven itself. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

Roger Sayle wrote: Hi Mark and Richard, On Fri, 19 May 2006, Mark Mitchell wrote: Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for MIPS on the GCC 4.1 branch? (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part

Re: Revert patch for MIPS TImode functions for 4.1.1

Andrew Pinski wrote: On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is only a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case

Re: Revert patch for MIPS TImode functions for 4.1.1

whether that option is viable as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

. Of course, we'd rather not have to choose. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C FE question: Is this test even valid?

is ill-formed GNU C, since the machine in question know not have a register named unknown register. One could also argue that this check should be done closer to the FE, but that's orthogonal to the validity of this test case. Yes, I think the check should be done closer to the FE. -- Mark

Re: C FE question: Is this test even valid?

Diego Novillo wrote: Mark Mitchell wrote on 05/19/06 14:54: Yes, this test case is valid; the code is ill-formed GNU C, since the machine in question know not have a register named unknown register. ^ I can't parse

Re: PATCH: Update src/intl from gcc/intl

DJ Delorie wrote: I will unless you want to add this to the libiberty merge you do now. I don't mind adding it to my script, if people agree that's what they want. It's just that nobody asked :-P I hereby request that you add automatic intl/ merging to your script. :-) -- Mark Mitchell

Re: Revert patch for MIPS TImode functions for 4.1.1

that, so that I can start an RC2 build. Thanks for working on this difficult issue. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Wrong link?

Gerald Pfeifer wrote: Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to install this there as well? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

Martin Michlmayr wrote: * Mark Mitchell [EMAIL PROTECTED] [2006-05-22 11:36]: I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. Did anyone investigate those abi_check failures I (and others) have seen? See http://gcc.gnu.org/ml/gcc

Re: Revert patch for MIPS TImode functions for 4.1.1

Mark Mitchell wrote: Richard Sandiford wrote: Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf. Mark, what do you think? I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. So, we could declare that Fortran

LTO Branch

for the various components, and we'll be looking for feedback as we go. -- David Edelsohn Mark Mitchell Diego Novillo Ian Taylor Kenny Zadeck

Re: LTO Branch

then, but the need for link-time optimization hasn't gone away -- so it's time to get moving! We've now created branches/lto in the GCC repository to start doing LTO work, beginning with: Can you also update svn.html? Done, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: GCC 4.1.1 RC1

/changes.html, which highlight important changes. I'd imagine you might want to update bugs.html, in this case? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.1 RC1

DJ Delorie wrote: I'd imagine you might want to update bugs.html, in this case? Or, perhaps, branch's install.texi's Host/Target specific installation notes for GCC ? Yes, that's probably even better. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

<    1   2   3   4   5   6   7   8   9   10   >