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

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

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

- 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

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: 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: 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.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.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

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

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

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

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

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

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

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

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

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

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

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

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: 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.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

le.am is incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir. -- 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

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

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

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

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

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

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

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

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

GCC 4.1 RC1

mitters to apply to other branches. -- 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

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

Re: "cscope" type functionality

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

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

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

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

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

Status for releases, etc.

various outstanding issues. Thanks for being patient. -- 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

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: 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: 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: [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: [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

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

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

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

Jan 2006 16:55:54 - GOMP - Diego Novillo > > So I am requesting that we go through a 48 hour period starting Monday > (as the weekends are usually quiet for patch committing) for a stage 3 > type regression only/bug fixes. I'm inclined to agree. Any objections? -- Mark Mit

Re: -Wpointer-sign for GCC 4.1

Joe Buck wrote: > It is PR 25892. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RTL alias analysis

Richard Henderson wrote: > On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote: > >>I guess a secondary question is: is the workaround sufficiently useful >>in many of the problematic cases and sufficiently non-harmful in other >>cases as to merit inclusion, gi

Re: RTL alias analysis

f the problematic cases and sufficiently non-harmful in other cases as to merit inclusion, given that we don't have a better solution? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RTL alias analysis

Richard Guenther wrote: >>patch needs a paragraph-long comment explaining what the problem is and >>how this approach solves it. > > Ok, I'll try to come up with an explanation. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RTL alias analysis

Steven Bosscher wrote: > On Friday 20 January 2006 18:21, Mark Mitchell wrote: > >>Richard Guenther wrote: >> >>>A patch was also posted based on ideas in the audit trail. It's third >>>incarnation at >>>http://gcc.gnu.org/ml/gcc-patches/2006-

Re: RTL alias analysis

In general, I think the patch needs a paragraph-long comment explaining what the problem is and how this approach solves it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: -Wpointer-sign for GCC 4.1

nce you seem to have a handle on the outcome of the discussion, would you please create a Bugzilla entry for this, targeted at 4.1, explaining what it is the SC agreed to do? Otherwise, I'm certain to forget about this issue... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-01-15)

ments. Therefore, while we will enter Stage 1 as scheduled, we'll permit those projects already on the 4.1 projects list to be submitted and/or reviewed during Stage 2. However, because we will be in Stage 2, other patches of similar magnitude will need to wait until until GCC 4.3. -- Mar

GCC 4.0 Status Report (2006-01-15)

hat 4.1.0 is in reasonably good shape. After 4.0.3 has been released, I do not plan to make any more releases from the 4.0 branch, although (as with previous branches) another RM may step in to do that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2006-01-15)

n about a week of RC1; if there are problems reported for RC1, then we'll iterate. Therefore, if there are other regressions which you would like to see fixed for 4.1, now is the time! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?

s you say, it's just a recipe for trouble to be doing any code generation at all when errors have ocurred. At worst, we miss some diagnostics -- which we will then issue when the user recompiles after fixing whatever errors they had in the original code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Not using VAR_DECLs for temporary variables

k we should do the complete patch. I know it's going to be tedious to fix the uses of SSA_NAME_VAR, but I think that would be much cleaner, and will also avoid problems where we have a DECL (GVAR_DECL) that is missing fields that other parts of the compiler might expect a DECL to have. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Cleanups of TARGET_EXPR

o that f will construct the value directly into s. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Cleanups of TARGET_EXPR

he cleanups should not be run. However, if it were just "b ? TARGET_EXPR : something", then the cleanups should be run; that would be an orphaned use. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [C++] enumerators and check_initializer

E (decl)) != REFERENCE_TYPE); > > where one wanted to check that the decl is not a reference type? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ parsing regression?

up, and to look at this bug. Thanks for the analysis regarding the cause; that should help. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Ben Elliston appointed libdecnumber maintainer

Ben -- The GCC SC has appointed you as a maintainer of libdecnumber. Please add yourself to MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ parsing regression?

ecl. Was this > change intended? I'm not sure; please send me preprocessed source, and I will look into it. It's certainly possible that those changes broke something. What do you think the above code is supposed to mean? Are you declaring a constructor for CflFunctor, or an unname

Re: RTL alias analysis

the load. My guess at a solution is that when A (with alias set S_a) and B (with alias set S_b) are given the same stack slot, we should create a new alias set S_c which is a subset of both S_a and S_b, and give the combined stack slot that aliase set. -- Mark Mitchell CodeSourcery, LLC [EMAIL P

Re: Will there be a GCC 4.0.3 ?

begin work on that release shortly. The GCC 4.0.x branch is stable, so it's relatively easy to make a release. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2005-12-19)

ntention is to create the first 4.1 release candidate when (a) we've eliminated the P1s, and (b) it's at least January 19th. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

#pragma pack vs. zero-width bitfields

a few days. So, any disagreements? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

Re: g++.dg/ext/packed3.C

Nathan Sidwell wrote: > Mark Mitchell wrote: > >> struct Foo { void operator=(Foo const &);}; >> struct Baz __attribute__((packed)) >> { >>char c; >>Foo m; >> } >> >> void Bar (Baz *ptr) >> { >>ptr->m = s

Re: g++.dg/ext/packed3.C

s code to be invalid, and either issue a diagnostic, or at least be considered undefined behavior. (In my idea world, ptr->m has type "packed Foo" in this case, and it's not permissible to binding a "packed Foo" to a "Foo const&", so this would be invalid, but I could live with undefined.) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Nathan Sidwell as Morpho Technologies Co-Maintainer

The SC has approved Aldy's nomination of Nathan as a co-maintainer for the Morpho Technologies port. Nathan, please updated MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: C++ parser: Should we get rid of cp_parser_declarator_id?

nction? As Gaby says, perhaps we could mark the function inline, if you're worried about performance? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: LTO, LLVM, etc.

hared was not. That's why I think we should be talking about the effort required to implement the approaches before us, and the payoffs from where those approaches lead us, rather than generalities about design. (And, if you really want a prize, you can put "risk-adjusted" in fron

Re: LTO, LLVM, etc.

and of itself a problem -- but I'm happy to switch to LLVM, if we think that it's easier to make LLVM do what we want than it is to make Tree-SSA do what we want. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: LTO, LLVM, etc.

r as I know?) funded by any companies. You're correct that LTO, were it to proceed, might make this a killer issue, and then we'd have to attack it -- and so that work should go on the cost list for LTO. You're also correct that some of this work would also benefit GCC as a whole, in

Re: LTO, LLVM, etc.

but that I do agree that one wants the right representation for the job, and that Tree-SSA is not the best representation for optimization. So, if Tree-SSA is not replaced, it will almost certainly need to evolve. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

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