Re: RTL alias analysis

Upon reading the thread carefully, so do I. Would anyone care to prepare such a patch? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Request for 48 hours of just regression/bug fixes

at that point until our backs are against the wall right before a release. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Mainline not slushy

for previously registered Stage 1 projects that have not yet been comitted for whatever reason. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: sh64-elf fails to build with gcc 4.1

Joern RENNECKE wrote: > OK to backport to 4.1 if bootstrap on i686-pc-linux-gnu succeeds? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Reconsidering gcjx

er, and we certainly don't assume a GPL problem because GCC on Solaris invokes the Solaris assembler! Of course, we should definitely get the SC's buy in before making such a change of this magnitude. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Request for clarification on the 128bit long double requirments

now-or-never change in GLIBC.) Given that the GLIBC with the support is fully backwards-compatible with older GLIBCs, it seems that it would be possible to enable the support later on the GLIBC 2.4 branch, when compilers that can support the feature become available. Thanks, -- Mark Mitchell Cod

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

or quite some time. If there were significant objections, they should have been made immediately, and, if necessary, the SC involved at that point. Jakub has already indicated that the libstdc++ changes will not go on the 4.1 branch. I, too, believe those changes are too risky. -- Mark Mitchell

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

cision, criticize it, or ask the SC to intervene. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

Mark Mitchell wrote: >>it misses the point that many important resources in GCC are being used in >>fixing and testing this new feature, instead of putting GCC in shape for the >>release. So the release has been already delayed because of this, and will be >>even more

Re: Request for clarification on the 128bit long double requirments

again. Each platform will either change by the first > 2.4 release, or it will not change until the next ABI-changing release > (presumably 2.5, and not especially soon). Thanks for the clarification and explanation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: fvisibility-inlines-hidden

Howard Hinnant wrote: > Let me rephrase: It seems to me that fvisibility-inlines-hidden should > apply to all inline functions (both member and non-member). Does > anyone have an argument for why it should not be this way? I certainly do not. -- Mark Mitchell CodeSourcery [EMAIL

Re: Toplevel bootstrap only - where are we?

fway in between is just confusing. Let's make it happen. I'll help review patches in this direction, to the extent I can do so competently. However, I'll of course defer to the build system maintainers -- either on particular patches, or in general, if they determine I'm incompetent. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

Geoffrey Keating wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > >>However, the PowerPC GNU/Linux community seems to want this feature very >>badly, and has suggested that failure to incorporate these patches in >>GCC 4.1 would be very bad. My

Status for releases, etc.

various outstanding issues. Thanks for being patient. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "cscope" type functionality

owever, whether or not that proposal will be implemented is still an open question, dependent on demand, technological evaluation relative to other approaches for link-time optimization (notably, LLVM), and available resources. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pruning unused debugging types (enums/PR23336)

ge than the per-function vectors. Then, you'd have to walk the entire hash table, writing out each type for which at least one of the associated functions was written out, including being inlined into another function. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2006-02-14)

roval; please attach patches to PRs, and Cc: to me. Hopefully, the two P1s will be fixed tomorrow, and I can make a release candidate as early as Wednesday evening. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1 Status Report (2006-02-14)

6-02/msg00933.html I see Diego has now reviewed it. We'll proceed with the freeze as previously announced, at midnight, tonight, here in California. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pruning unused debugging types (enums/PR23336)

Aldy Hernandez wrote: > Do we keep a hash of functions that have been written out somewhere? Not to my knowledge. > I'd hate to walk the entire hash table each time we write out a function > searching for the types that function uses. Agreed. -- Mark Mitchell CodeSourcery [E

GCC 4.1 Branch Frozen

ae as much time as I'd hoped. My expectation is that RC1 will be available over the weekend. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "cscope" type functionality

PROTECTED] That's where discussion and patches will appear. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00

Olivier Hainque wrote: >>Mark, is it ok for Olivier to apply the patch mentioned here on >>4.1? > >> http://gcc.gnu.org/ml/gcc/2006-02/msg00251.html Yes, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1. Freeze

I plan to spin RC1 on Sunday morning, California time. Therefore, if you have outstanding patches, already approved for 4.1, please check them in Saturday. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 RC1

mitters to apply to other branches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Patch policy for branches

with the proposed plan is that it means that more scarce resources (RM, testers, etc.) are required over a shorter period, rather than being spread across time. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Patch policy for branches

Matthias Klose wrote: > Mark Mitchell writes: >> and the 3.4.x branch is official dead at this point. > > No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html My mistake; thanks for the pointer. However, that doesn't change the general thrust of my mail; the only issue

GCC 4.1.0 RC1

, file a bug in Bugzilla, and add me to the CC: list. Enjoy! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Bootstrap failure on trunk: x86_64-linux-gnu

that the object actually have that value if the program has invoked undefined behavior. So, if you have an 5-bit type, stored in a byte, and you manage to get 255 in that byte, and you read the value, you might see 255 at runtime -- but only because your program was busted anyhow. -- Mark

Re: Bootstrap failure on trunk: x86_64-linux-gnu

t; } you can happily assign "5" to this enum. The C++ front end correctly sets TYPE_MAX_VALUE in this case. I'm not sure what the situation is in C. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2006-02-23)

already submitted changes, spin RC2, and declare that all-but-final. However, I am not fully committed to this plan; I might still decide that RC1 is good enough. Therefore, if you have any strong feelings on this topic, now would be a good time to speak up! Thanks, -- Mark Mitchell CodeSourcery

Re: 4.1rc1 cross Ada build issue

Paolo Bonzini wrote: > Yes, http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00342.html was not > applied on the branch. It only affects Ada so it shuld be safe. Yes. Do you have a revision number handy? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 RC2

I will spin GCC 4.1 RC2 tonight. The only patch I plan to apply, relative to current sources, is Paolo Bonzini's Ada patch. GCC 4.1 RC2 will become the final GCC 4.1.0 release within a few days, unless disaster occurs. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

Re: GCC 4.1 RC2

Paolo Bonzini wrote: > Mark Mitchell wrote: >> I will spin GCC 4.1 RC2 tonight. >> >> The only patch I plan to apply, relative to current sources, is Paolo >> Bonzini's Ada patch. > > ... which is revision 108058. I gather that you want to apply it yours

GCC 4.1 RC2 available

rings. Assuming that no disasters are reported, I will make the final release early next week. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Tuples for GIMPLE

ical approach is that it might let us start incoporating the leaner trees into the rest of our IL; we'd start having the idea of trees-without-a-TREE_CHAIN. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

nal include dir > ($libdir/gcc/$target_alias/$version/include) I will review this issue before the final release. My current expectation is that I will apply your patch, test locally, but not produce an RC3. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: serious regressions in gcc 4.1 branch

week. The other regressions have been retargeted at GCC 4.1.1. They will not be fixed in GCC 4.1.0. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.0.3 Status Report (2006-02-27)

want to be able to stay close to the 4.1 release date. So, as of midnight Wednesday, GMT - 8, the 4.0.x branch will be frozen. Please do not apply patches for problems not fixed in 4.1.0. Then, I'll build RC1 on Thursday. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

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 toni

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

der switches, but I have verified 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 lo

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

le.am is incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.0 Released

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 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 Mitch

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

ot a thick skin, and I feel omfortable exercising my own non-algorithmic discretion to do 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

e adding 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

ackported patch is the cause. The first step is to address regressions 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

Re: GCC 4.1.0 Released

ps, for all time, 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 ??

riendly about my patch, but I can believe 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

tual prerelease 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

t; on x86 cross sh4-unknown-linux-gnu > looks fine. If these patches 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

t linking with -mwindows would work, 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

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

Re: Problem with pex-win32.c

s: Cygwin Xterm parent spawn: Pops up DOS window. parent nostd: 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-33

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

-4.2-20060304.tar.bz2 = 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

Imported GNU Classpath 0.90

udes an update to the fdlibm library). Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part

Re: gcc-4.2-20060304 is now available

-C compiler as objcp depends on c++ also? Yes, but so what? :-) Creating these separate modules seems somewhat pointless given the core 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

/gcc-4.0.3, (there is no such page). That > link should 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

f "current changes" > for 4.1.0 on the main page? Now corrected, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

term issue per se. And, even if this considered a Cygwin X client bug, 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

- as > an attachment, please. 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 a

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! --

Re: Problem with pex-win32.c

me wheels. All the more reason to get this into libiberty... :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with pex-win32.c

ill make sense for to fix libiberty; we 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 Cygw

Re: Problem with pex-win32.c

s in mainline libiberty; it's not a lot of code, and completely 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

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

ream sources, please submit those changes to the GLIBC maintainers ASAP. Because RMS has approved the use of GLIBC's software floating-point code in GCC's runtime libraries, using GPL + exception, the correct thing for Joseph Myers to do with his recent patch is to mark those files as not pa

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

Richard Guenther wrote: > On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Richard Guenther, would you please add a README to libgcc-math >> explaining that it that the GLIBC code is not part of GCC, as per the >> web page above? Also, please document that all of

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

mission, if you want. Please do not ask me to interpret or justify all of the rules; I don't understand the issues sufficiently well. I am just passing along the results of a long discussion with RMS on the SC list. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

s, and that they should be willing to accomodate reasonable changes, even if those changes aren't directly beneficial to GLIBC itself. -- 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 >&g

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

o GPL/LGPL issues. So, I think you should remove the dbl-64 code until this is resolved, or at least prevent it from being compiled 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

citly indicate 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

y stated, if there is contrary information from FSF lawyers, 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 originall

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

PROTECTED] He generally responds to email within 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

* Permission to use, copy, modify, and distribute this >> * software is freely granted, provided that this notice >> * is preserved. >> * >> */ > > Mark Mitchell wrote: >> My guess is that it's OK to inc

GCC 4.2 Status Report (2006-03-17)

March 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, -- Mar

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

cial authority to make 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 definite

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: [FYI] Building the whole Debian archive with GCC 4.1: a summary

Matthias Klose wrote: > Summary: > > GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. Thank you for doing this, and for reporting the results, and for filing the bugs! This is, in my opinion, pretty good news for GCC. Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: GNU Pascal branch

ng any judgement on the merits, adding GPC to the repository would 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)

y can't use the lists to advertise job listings, but new players can. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

ust use the FSF's job board (which already meets FSF requirements and is policed 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

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

l spam and things better 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)

, 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 for the web pages, and ask Gerald to find a place to put it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Posts don't appear on the gcc mailing list...

here someone who can give me a hand with this? Thanks! Mark

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

IT department does. I'm OK with any 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

gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs

with gcc 3.4.x on sparc. There was a post on the gcc-help list with no reply, and several other references around the web as well but none with solutions. I'd really appreciate it if someone could point me in the right direction on this one... Do I need a patch for gcc 3.4.4 to build on spar

Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs

g GNU make version 3.80 I'm quite sure the kernel supports 64 bit - I've never had to disable anything for that before to get previous versions to build on sparc... Thanks Mark - Original Message - From: "Eric Botcazou" <[EMAIL PROTECTED]> To: "Mark

Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs

Ok - it built this time. I guess I should read the instructions - my fault... Thanks for the help! Mark - Original Message - From: "Eric Botcazou" <[EMAIL PROTECTED]> To: "Mark Cuss" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, April 11, 2006 10:52 AM Su

Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

nge at this point, 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

<    6   7   8   9   10   11   12   13   14   15   >