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

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?

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

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: 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: Cleanups of TARGET_EXPR

o that f will construct the value directly into s. -- 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: 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

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

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

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

New libquadmath maintainers: Jakub and Tobias

Jakub, Tobias -- The GCC SC has appointed you as maintainers of libquadmath within GCC. Please update the MAINTAINERS file to reflect your new positions. Congratulations! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Liqin Chen now maintainer of SCORE port

ntain the port from this point forward. Please remember to update the MAINTAINERS file. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC Release Management

teful for all of that and, more generally, for having had the opportunity to be involved in such an important open-source project. Thank you, -- Mark Mitchell CodeSourcery / Mentor Graphics m...@codesourcery.com (650) 331-3385 x713

Re: bitfields: types vs modes?

their > ports as well. Great! > What's the next step? At the risk of being naive: implement it. I'm not quite sure what you're looking for here? I'd assume that we should try to do some of this at the tree->rtl conversion point, in a platform-independent manner, but I

Re: removing -Wtraditional-conversion

ovide tools to introduce or remove prototypes; it's useful for people who still have (even partially) K&R codebases. And there are plenty of such people. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC Status Report (2009-08-23)

7 P30 - 4 --- --- Total 120 + 3 Previous Report === http://gcc.gnu.org/ml/gcc/2009-07/msg00607.html The next report for 4.5.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC Status Report (2009-08-23)

ird major feature, if we can reach consensus that it's a good solution to the problem it's set out to solve. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.4.2 Status Report (2009-09-01)

Status == The 4.4 branch is open for commits under the usual release branch rules. The timing of the 4.4.2 release (at least two months after the 4.4.1 release, so no sooner than September 22) at a point when there are no P1 regressions open for the branch) has yet to be determined. Quality

Re: apple blocks extension

;contribution" step; simple publication may not be sufficient. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [PATCH] Adjust develop.html to reflect recent practice

Richard Guenther wrote: > 2009-09-20 Richard Guenther > > * develop.html: Adjust to reflect recent practice. OK. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Adjust primary/secondary platform lists

ck of active maintenance of GCC, by Apple or otherwise, for x86 OS X). Applied. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 Index: gcc-4.5/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/criteria.h

Re: Updating Primary and Secondary platform list for gcc-4.5 ???

make sense to me. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: (C++) mangling vector types

or less different about this change then other mangling changes, as far as I can tell. It's another case where we've discovered an inability to implement the full language with the current scheme, and have therefore been forced to make a change. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: (C++) mangling vector types

ather than just a numerical version. That sounds theoretically right to me, but awfully complicated in practice. Do we have another libstdc++ ABI change coming? I'd suggest doing this as -fabi-version=4, and making that the default at that point. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: (C++) mangling vector types

long as they aren't actually trying > to share affected data structures. So, do you consider ABIv3 there only as a theoretical conformance option? In other words, not something we're going to make the default in any forseeable future? (Those aren't meant to be rheto

Re: (C++) mangling vector types

t;. That would be your version 2.1, but arguably more logically coherent in that it would be expected to move in the future if/when we find another feature we can't implement due to current mangling issues. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: (C++) mangling vector types

sion. This still seems a lot of complexity to me, and I still think inserting a new version between 2 and 3 is odd. If we need the complexity, I think we have to introduce a new orthogonal option for vector mangling, independent of the ABI version, but implied by ABI version > 4. -- Mark Mit

Re: (C++) mangling vector types

version, but implied by ABI version > 4. > > How is mangling orthogonal to the ABI? It's certainly possible to have ABIv2-with-vector-change and ABIv2-without. I never claimed that they were the same ABI. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?

lways pass -Wno-missing-braces. But, that's not a position I'd argue for strongly. Whatever we do, I think the C and C++ front-ends should have the same behavior. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?

is now: struct B { struct A a; int j; }; and I write: struct C c = { 1, 2 }; ? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?

rs, not -Wmissing-braces. -Wmissing-braces is explicitly about not having all the brace groups fully specified. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: On strategies for function call instrumentation

f(temp) before you put in your asm, and if you're in C++ land, you're now doomed, since creating named temporaries can change the semantics of programs. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: What's the policy for bug priorities, again

ion is here. That doesn't mean we should fix the ICE. The right outcome might be to disable the pass, or to do nothing at all. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.5 Status Report (2010-02-21)

--- --- Total 124 + 13 Previous Report === http://gcc.gnu.org/ml/gcc/2010-01/msg00398.html The next report for 4.5.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.5.0 Released

this release. GCC 4.5.1, with corrections for any critical defects reported in GCC 4.5.0, is expected in July, 2010. As always, a vast number of people contributed to this GCC release -- far too many to thank individually! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.5.0 Released

t improvements since GCC 4.4.x; they don't all fit in an announcement. Of course, you're entirely free to publicize plug-ins as you like in any forum you find appropriate. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.5.0 Released

release gets out there. I promoted GCC 4.5.0 at the Linux Foundation Collaboration Summit last Friday in San Francisco. So, you're right, I'm not writing a beautiful white paper, but I'm very happy to promote GCC. (Since I don't get to write much code these days, that ma

Convert Blanket Write Privileges to Global Reviewers

t the attached patch momentarily. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 2008-10-01 Mark Mitchell <[EMAIL PROTECTED]> * MAINTAINERS (Blanket Write Privs): Change to Global Reviewers. Index: MAINTAINERS =

Re: Convert Blanket Write Privileges to Global Reviewers

Eric Botcazou wrote: >> 2008-10-01 Mark Mitchell <[EMAIL PROTECTED]> >> >> * MAINTAINERS (Blanket Write Privs): Change to Global Reviewers. > > This is apparently incomplete, see the Non-Algorithmic Maintainers section. It's a fair question. I will rai

Re: [lto][RFC] Do not emit hybrid object files

rid should be the default. There are lots of reasons LTO isn't going to work for many users for a while (like, for example, a bug in LTO), and having hybrid object files gives them an easy way to succeed. As with any argument about defaults, it depends on what you think is the "typical"

GCC 4.4.0 Status Report (2008-10-21)

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

Re: [RFC] Remove -frtl-abstract-sequences in 4.5

ith David. Code that is known-broken, not known-useful, and which nobody has plans to fix should just be removed ASAP; it's just a hazard to users. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: testsuite, simulators, and argv[0]

ptimizing the program away. So, I suggest doing something like: volatile char *x = "pr36321.exe"; and passing x to the function, instead of argv[0]. A patch along those lines is pre-approved. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: testsuite, simulators, and argv[0]

Andreas Schwab wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > >> However, I think an even better fix is just to hard-code the string and >> make it volatile. Presumably, the use of argv[0] here is just to keep >> the compiler from optimizing the prog

Re: testsuite, simulators, and argv[0]

DJ Delorie wrote: > How about this? OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.4.0 Status Report (2008-11-27)

cc.gnu.org/ml/gcc/2008-11/msg00343.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Odd performance regression with -Os

a fairly nasty regression on embedded targets with no > multiplier, where people are likely to use -Os. Sounds to me like > it qualifies for 4.4 I agree. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [lto] [RFC] Design proposal for debug support in LTO

format as in-memory representation, any more than the current dwarf2out.c does; instead, you use an internal representation isomorphic to that. I'd imagine you could just start with the internal data structures dwarf2out.c already has. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Use longlong.h?

th that may not be feasible. I have suggested this change to the SC. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: We should backport gcc 4.4 regression testcases to gcc 4.3 branch

sure that they pass before committing them. Otherwise, we're creating noise. Bear in mind that some tests require features that weren't available in older versions. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Use longlong.h?

Mark Mitchell wrote: > Joseph S. Myers wrote: > >> As code shared by GCC and glibc I would suggest the same license notice as >> soft-fp (LGPL >= 2.1 + exception) to allow an identical file to be shared. >> (Indeed, soft-fp uses this header.) The version in G

Re: New GCC Runtime Library Exception

d)? We should just update the licenses on the trunk. The change from GPLv2 to GPLv3 in the midst of the 4.2.x release cycle was confusing to people. I see no reason to do that again. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: New GCC Runtime Library Exception

volunteered to prepare a patch and got the patch ready by the time 4.4 > branches it should just go on trunk for 4.5? I think this change should be part of 4.4. I was planning to work on some of the patch bits myself, and to ask others to volunteer for some of the other bits. Thanks, -- Ma

Re: New GCC Runtime Library Exception

ding the files that currently have an exception and updating them to the new exception -- a single, uniform exception across the source tree -- is going to be a big win. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: New GCC Runtime Library Exception

hat GCC 4.4 should > be released with this new license; does this match your understanding? Yes, definitely. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC & OpenCL ?

erested in talking to them. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

ion, or with a compiler distribution) would make sense. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC & OpenCL ?

fies some library functionality; that could be provided in a library that included hand-written assembly code, or was generated by some non-GCC tool. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: PR 39076 Backport a patch for GCC 4.3

t; http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00907.html . > > Is it ok to backport this patch into gcc-4.3 after regression testing? Yes. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Closing 4.2 branch

and removing "4.2/" from the summaries of 4.2 regression bugs > that remain open as also being regressions in future releases. Let's add a checklist for that as well; it's a mechanical process that we may as well document. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: proposal for improved management bugzilla priorities/release criteria

o go out the door. So, I'm all for guidelines, and I agree that 49 vs. 50 isn't itself a big deal. But, I think that Paolo's criterion should not be interpreted literally. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: proposal for improved management bugzilla priorities/release criteria

ld be P1 ... No, that misses the point. A mass of bugs, each itself not too critical, can still make a release that is of substandard quality. Think of the integral of perceived quality over the intended user-base. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: proposal for improved management bugzilla priorities/release criteria

e of distinguishing at this point. If there were thousands of bugs it would be different. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.4.0 Status Report (2009-02-16)

Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. As stated previously, the GCC 4.4 branch will be created when there are no open P1s and the total number of P1, P2, and P3 regressions is under 100. We've achieved that, but are st

Re: ASM_SPECS on recent GCC 4.3.3 (4.X)

x27;s some confusion here. There is no relationship between the ASM_SPEC definition in a config *.h file regarding options to be passed to the assembler and the old "asmspec" parameter to rest_of_decl_compilation, which related to uses of the "__asm__(...)" extension in the s

Re: ASM_SPECS on recent GCC 4.3.3 (4.X)

r configuration. You will have to get out the debugger and preprocessor to work out what's going on. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Split Stacks proposal

7;s ability to introduce copies. It says "Here are where copies occur; some of these can be optimized away." It doesn't say anything about inserting more copies. So, depending on exactly how this works, it might or might not be technically standard-conforming to introduce copies at t

Re: GCC 4.4.0 Status Report (2009-02-16)

the door, and that we're working to make that happen. Given the way that the FSF works (i.e., slowly and deliberately), getting excited will likely be counterproductive. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: C++ FE stripping const qualifiers from function prototypes (bug or feature?)

and don't forget to think about restrict) are removed from the type of function parameters when computing the type of the function. However, they do of course apply *within* the function; you cannot change a parameter of type "const int i". -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: C++ FE stripping const qualifiers from function prototypes (bug or feature?)

Daniel Berlin wrote: > But if it was following this and removing const qualifiers, shouldn't > it have remove the const from const char * too? > Or am i missing something? No, that is not a top-level qualifier. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.4.0 Status Report (2009-03-13)

imposes. As an SC member, I can (and do) lobby the FSF, but when given an explicit directive my choices are to go along with FSF policy, or resign. I don't think it's appropriate to disobey the FSF's directives in the FSF's official repository. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.4.0 Status Report (2009-03-13)

that proprietary programs are virtuous. The GPL allows me to do that and to distribute the resulting binaries and so forth. But, in the FSF's official repository, that would clearly be a breach of faith. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.4.0 Status Report (2009-03-13)

ngly enough I'd resign, but I'd not act in defiance of that policy while remaining in the cabinet. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.4 Branch Created

mechanical patch set made to the web site. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 Index: htdocs/buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/buildstat.html,v retrieving revision 1.17

Re: GCC 4.4 Branch Created

think we can just remove it. It's not part of GCC proper. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.4 Branch Created

n appeal decisions they don't like to the SC). I agree that this is a good strategy. So, let's go ahead. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC + libJIT instead of LLVM

certainly a good one. I believe that's a usage model that will become increasingly important over time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: bitfields: types vs modes?

aborate with you on implementing them. If not, there may be still be some common parts. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: bitfields: types vs modes?

your target and > mine. I'd like to know how many of the assumptions above are valid on your target. I would imagine that many of them are. In which case, the existing hook is good enough; we just need to implement middle-end behavior depending on the hook. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: The gcc-in-cxx branch now completes bootstrap

Ian Lance Taylor wrote: > My plan going forward is as follows (when we are back in stage 1): FWIW, I think this is a great plan. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC + libJIT + Domain Specific Languages Concept Integration

t them, and encouraging the FSF to accept them, rather than to push such people away. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Using MPC Library with GCC

he SC could be involved there, if no decision can be reached, but I hope that we can reach consensus and therefore avoid having to ask the SC to arbitrate. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Slush: Bug-Fixes Only for Middle End and Primary Platforms

bit too much change a bit too quickly. When changes of this magnitude go in, we should probably wait a few days to see if stabilization is required before introducing another change of large magnitude. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

m what would be determined by the link-time probe. So, I think that this is an orthogonal issue to the question of how we should probe. FWIW, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Trunk freeze next Friday morning GMT for cond-optab merge

whether or not we've had enough slush, let me know. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Problems with in-tree host libraries (gmp, ppl, etc)

point where we're doing "staged installs", instead of the current mess -- but the more we put into the build system the more complex it becomes. I think we should leave the process of building and installing components to packaging systems like RPM or .deb or Cygwin. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms

Mark Mitchell wrote: > We're in Stage 1, and in Stage 1 big changes happen -- and then there is > naturally some instability. We clearly have some instability at > present, so we need to slow down until that's resolved. It looks like we have successfully resolved many of the

Re: Trunk freeze next Friday morning GMT for cond-optab merge

nd then in order to give you the best possible chance at getting this done on Friday, as you've requested. Good luck! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.5.0 Status Report (2009-05-05)

l/gcc/2009-04/msg00565.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Using MPC Library with GCC

let's say one more week) to comment. If that week passes without negative comment, let's start coordinating how to move forward with it. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GCC 4.4.1 Status Report (2009-05-05)

80 + 5 P30 - 9 --- --- Total82 - 2 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery m...@codesourcery.com

Re: GCC 4.5.0 Status Report (2009-05-05)

ootstrap on ARM is still broken. Is this PR 39978? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GCC 4.4.1 Status Report (2009-05-05)

Jack Howarth wrote: >Shouldn't PR3 be higher than a P3 since it puts the compiler > in an infinite loop and is a regression from gcc 4.3.x? P3 means "nobody has reviewed it yet". You filed it after I did my issue review yesterday. I've now upgraded it

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

-O0 code is bad enough already; and this just makes > more work for the compiler. I agree. What was the underlying fundamental change here that made the ARM strategy stop working? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]

Paolo Bonzini wrote: > I'll go for Tuesday unless I get a "go" from either Richard Earnshaw > (ARM maintainer and global reviewer) or Ramana Radhakrishnan (who's > taking care of bootstrapping the ARM-fixing patch). That's fine. Thank you for taking the ARM

Re: Using MPC Library with GCC

hink this is the best option. Please make sure to open a P1 PR for 4.5.0 indicating that we should throw the hard-requirement switch. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [PATCH][RFC] Adjust the middle-end memory model

rse this happens with structures and such...) Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Multilib for ARM in thumb2 mode

nfigurations, without covering all the cases people care about. But, this is a significant effort because of lot of stuff is baked into the build process. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

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