GCC 4.1.2 Status Report

the answers to the issues above. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.2 Status Report

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

Re: GCC 4.1.2 Status Report

the user compiles a large application and it doesn't work, there's no hint that -fno-strict-aliasing is the work-around. It's not like an ICE that makes you think Hmm, maybe I should turn off that pass, or compile this file with -O0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650

Re: false 'noreturn' function does return warnings

good way to represent a control-flow barrier at user level. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.2 RC2

in Bugzilla. Based on the absence of issues reported for GCC 4.1.2 RC1, I expect GCC 4.1.2 to be identical to these sources, other than version numbers, and so forth. I intend to spin the final release early next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US Daylight Savings Time Changes

for that. Java is not a major release priority, and at this point I'm not anticipating a 4.1.2 RC3. However, I would suggest that we apply the patch to the 4.1 branch after 4.1.2 is released, assuming that the Java maintainers are comfortable with that. Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: GCC 4.1.2 RC2

and this one appears to have regressed since the case is from 2003. This looks to be at worst a minor code quality issue. 6. 22_locale/num_put/put/wchar_t/14220.cc fails with sparc64 -fpic/-fPIC. This is unfortunate, but I don't see any evidence of a major blocking issue there. -- Mark

Re: GCC 4.1.2 RC2

the last RC and the actual release. So, I feel that I have no choice but to do a 4.1.2 RC3 with a more conservative version of DECL_REPLACEABLE_P. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.2 RC2

Richard Henderson wrote: On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote: Does it seem overly aggressive to you to assume f cannot throw in g, given: void f() {} void g() { f(); } where this code is in a shared library? Yes. If F is part of the exported

Re: Some thoughts and quetsions about the data flow infrastracture

to give the special-case information to the core DF code, then I'm sure everyone would agree that it made sense to use something different. But, that would be only in extraordinary situations, rather than having lots of reinvention of the same infrastructure. -- Mark Mitchell CodeSourcery [EMAIL

Re: GCC 4.1.2 RC2

Richard Henderson wrote: On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: But, aren't big C++ shared libraries rather different? Does KDE actually use throw() everywhere, or visibility attributes? But, presumably, most people don't

Re: GCC 4.1.2 RC2

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

GCC 4.1.2 RC3 Cancelled

and Joseph's update of translation files. If the build change for non-standard shells is also checked in tonight that's fine; if not, there's a good workaround. So, my current intent is build the final 4.1.2 release tomorrow evening in California. Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: Some thoughts and quetsions about the data flow infrastracture

is whether it makes the generated code faster. So long as it doesn't make the generated code slower, and so long as the APIs seem well designed, and so long as it doesn't make the compiler itself too much slower, I think it's a win. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.2 RC3 Cancelled

not to be locally bound in shared libraries (which it determines by checking flag_shlib) and flag_shlib is generally set if flag_pic is true. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.2 RC3 Cancelled

-skip-if { *-*-* } { -fpic -fPIC } { } } */ double a; void t() { I think this makes sense. At worst, it's overly conservative, and the test would pass on some targets using those flags, but that's not a big deal. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

4.1 branch open

The 4.1 branch is now open for changes under the usual regression-only rules for release branches. Here are the changes that I commited during the release process. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 2007-02-14 Mark Mitchell [EMAIL PROTECTED] * DEV

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

branch in the usual way. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-02-19)

) March 31. Feedback and alternative suggestions are welcome, of course. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

.GemsFDTD-18.3% 465.tonto -2.5% 470.lbm -4.1% 481.wrf -2.7% What does that translate to in terms of overall score? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

choices are revert the patch and accept the bugs, or vice versa. Is there any reason to expect the bugs to be particularly more prevalent in 4.2 than they were in 4.1? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

on Intel Core2 Duo at -O2 optimization level. Do you happen to have a 4.1.x baseline to compare those against? Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. -- Mark Mitchell

Re: GCC 4.2.0 Status Report (2007-02-19)

trying to put as much of it as possible into being RM and C++ maintainer. However, that PR is in the list of open 4.2 PRs, so when I next make a pass over those PRs, I'll certainly look at it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-02-19)

by other improvements. If someone with a different chip is willing to provide the same measurements, that would help eliminate Intel-specific characteristics in the data as well. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Installing GCC documentation: Why a nonstandard title page?

be; that seems like a good thing. However, please avoid the bikeshed: we can all fuss over what font size to use, etc., but there's not much upside. I vote you pick something, and we all accept it. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

Grigory Zagorodnev wrote: Mark Mitchell wrote: Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

sense to compare unmodified FSF 4.2 compilers with distribution-optimized 4.1 compilers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFC: Constructor and destructor priority attributes

. The attribute syntax above works in both C and C++, and is backwards-compatible; without the (N) you just get the default initialization priority, as you do at present. I plan to merge this functionality to the GCC mainline. Does anyone object to this feature, in principle? Thanks, -- Mark

Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000

? Are you able to try reverting the aliasing patches to see how much of an impact they have on Itanium? It would be interesting to know how that compares with the 4% on IA32. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Who should fix platforms broken by extern inline hack?

. This patch (not yet approved) is my contribution to fixing the problem. http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html Please let me know if you feel this has gotten stuck, and I will try to help move it forward. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

GCC 4.2.0 Status Report (2007-03-04)

. :-) Of course, that's not to say that non-maintainers shouldn't contribute as well! Let's get it done! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 [1] http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html [2] http://gcc.gnu.org/bugzilla/buglist.cgi?query_format

Re: Signed overflow patches OK for 4.2?

are particularly pretty. Ian, please do the backport and check in the changes as soon as you can. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-04)

Manuel López-Ibáñez wrote: On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote: After reviewing all of the traffic[1] that stemmed from my previous status report, I've decided that, indeed, it makes sense to steam ahead with GCC 4.2.0 based on current GCC 4.2.0 release branch. I ask special

Re: GCC 4.2.0 Status Report (2007-03-04)

, but I've added a link to your message to the audit trails. Optimistically, someone might miraculously fix them, but it's very helpful to know that that's going to be unlikley. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC1 Status

* Jerry DeLisle * David Edelsohn * Steve Ellcey * Ben Elliston * Daniel Franke * Kaveh Ghazi * Richard Guenther * Richard Henderson * Geoffrey Keating * Thomas Koenig * Simon Martin * Andrew MacLeod * Mark Mitchell * Brooks Moses * Joseph Myers * Alexandre Oliva * Andrew Pinski * Mark Shinwell

Import GCC 4.2.0 PRs

for initializing arrays of pointer-to-member functions in C++. * PR 30590 (Guenther, Merill) -- Wrong code generated by NRV. * PR 30700 (Hubicka) -- Cgraph causes undefined references. * PR 30704 (Edelsohn) -- Bad code generation for long long on big-endian targets. -- Mark Mitchell CodeSourcery [EMAIL

Re: Import GCC 4.2.0 PRs

Ulrich Weigand wrote: Mark Mitchell wrote: * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked to reload, but he's not sure what to do there. Perhaps Ulrich can help. This description doesn't appear to match the bugzilla record. Maybe you're referring to PR 28675

PATCH: make_relative_prefix oddity

? The patch below (which is against an older version of libiberty, and might need updating) fixes it. Assuming you agree that this is a bug, would this patch (with updating and testing) be OK? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: libiberty/make-relative

GCC 4.2 branch snapshots disabled

testing on the actual prereleases, as those are most likely to contain any defects that I might introduce into the actual release as well. (*) I guess this should really be Beta 1; it's not quite a release candidate, yet, in that I fully expect changes after this point. Thanks, -- Mark Mitchell

RFH: G++ manual page in GCC 4.2.0

for releaes), doc/gcc.1 is in the source directory. VPATH finds it, so the dependency is satisfied, but the copy doesn't work. I intend to fix this by changing the rule to be: cp $ doc/g++.1 which will resolve VPATH correctly. Does anyone see a problem with this plan? Thanks, -- Mark

GCC 4.2 branch comparision failure building Java

The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: Comparing stages 2 and 3 Bootstrap comparison failure! ./java/parse.o differs ./java/parse-scan.o differs Has anyone else seen this? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)

wand, that would put the right XFAIL goo into all tests before every release so that all users who built the toolchain correctly always got zero FAILs, I would do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

choice. Like Ian, I think the macros above are fine. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

Joseph S. Myers wrote: On Tue, 13 Mar 2007, Mark Mitchell wrote: The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: Comparing stages 2 and 3 Bootstrap comparison failure! ./java/parse.o differs ./java/parse-scan.o differs Has anyone else seen this? I'm now looking

Re: GCC 4.2 branch comparision failure building Java

a version of GCC 3.4.x (built by CodeSourcery) as the bootstrap compiler. It does seem like a suspiciously similar situation, though; I'm sure that Joseph will be able to tell us if the problem is reproducible with GCC 3.4.x. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

, but if you know whether it's going to break, let me know. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

the Makefiles, if there are any more such problems. As Joseph's noted, the Java problem is already gone on mainline, thanks to the ECJ integration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

Paolo Bonzini wrote: Mark Mitchell wrote: Paolo Bonzini wrote: IIUC, the problem only manifests while *building* the release candidates, not for users of the release candidate. For 4.2, my suggestion is to just use a bootstrap4 while building the RC. That's an attractive idea. But, I'd

GCC 4.2.0 RC1

first filing a PR, as I am unable to keep track of all the issues if they are not in the database. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

) is unquestionably something that we want to do anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

and runtime libraries.) So, I still believe that I'll be able to build GCC 5.0 (on hardware available at that point) in less time than it took to build GCC 3.4 (on hardware available at that point). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

disagreement about that. I thought the plan was to this in TYPE_LANG_SPECIFIC, etc., so that it's not a generic effect on all trees? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

starting to prefer (2). It's a simple solution, and pretty efficient. Anyone want to champion (1) or (3)? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-22)

Mark Mitchell wrote: There are still a number of GCC 4.2.0 P1s, including the following which are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with -- as near as I can tell, based on Bugzilla -- the responsibility parties. PR 29585 (Novillo): ICE-on-valid PR 30700 (Sayle

Re: [patch] generated string libraries -Wformat

, but it might help Bruce to know for sure whether he's heading in a direction you're likely to approve. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-22)

Joseph S. Myers wrote: On Thu, 22 Mar 2007, Mark Mitchell wrote: Joseph, would you please take a look at PR 31136? Andrew believes this to be a front-end bug. I don't think this is a front-end bug. Thank you for investigating. (OK to commit this patch to mainline subject to the usual

Re: GCC 4.2.0 Status Report (2007-03-22)

it with an assert.) If that works, it's OK. If not, and you want to punt it back, go ahead. Thanks again for working on this! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: error: no newline at end of file

be overhauled at some point. But, this is it's current state, and it's been that way for a long time, so to resolve this issue, we should just play the same game. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: GIMPLE tuples. Design and implementation proposal

at serialization time. Then, when you deserialize, you could just leave them self-relative, or swizzle them back. Man, playing with all these ideas would sure be easier if you could make a class and overload * and - -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFA] C++ language compatibility in sources [was RE: Add missing casts in gengtype-lex]

choose to do that, as everyone agrees that this is good stuff to have! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Maintainers for C preprocessor

the MAINTAINERS file to reflect your new appointment, and thank you for agreeing to take on this responsibility! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: error: no newline at end of file

error messages see the message. They can control whether the message is an error or a warning via -pedantic-errors (or the C++ front-end's -fpermissive). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-04-15)

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

Re: GCC 4.2.0 Status Report (2007-04-15)

, is likely to introduce new bugs, no matter how positive its overall impact. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-15)

to be conservative and put the full GPL notice on all of them. If it doesn't apply because the file is too small, whoever wants to use it in some non-GPL way can assert that fact if they want. Is there some reason that putting the GPL on them is bad/wrong? Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: GCC mini-summit - compiling for a particular architecture

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

Re: GCC mini-summit

, and various other opinions that have been presented to me. I've got some ideas, but I want to let them percolate a bit before trying to write them down. In any case, I want people to know that I'm listening. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC mini-summit - compiling for a particular architecture

, by checking some property of the back end, that would be superior. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC mini-summit - compiling for a particular architecture

Kaveh R. GHAZI wrote: On Mon, 23 Apr 2007, Mark Mitchell wrote: I'm certainly not trying to suggest that we run SPEC on every architecture, and then make -O2 be the set of optimization options that happens to do best there, however bizarre. Why not? Is your objection because SPEC doesn't

Changes to PR prioritization policy

not a maintainer, but you want to make one of the changes above, lobby a maintainer. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-04-24)

. I've gotten a little paralyzed with this release. I've wanted to take some combination of (4), (5), and (6), and I've made a hash of it. I'm going to cut my losses and 4.2.0 out the door. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-24)

found the problem, I will send a patch once it passes regtesting. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-24)

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

GCC 4.2.0: Still planning on RC1, etc.

In case anyone here sends me an email, and gets my vacation auto-reply for the next week: I do still plan to proceed with the 4.2.0 release schedule in my last status report. FYI, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC2 Building

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

Re: GCC 4.2.0 RC2 Building

Mark Mitchell wrote: Zdenek, I would still be interested in a fix for PR31360. From the audit trail, it looks like your patch for this PR on mainline causes another problem (PR 31676), and that you are not working on PR 31676 because you cannot build for powerpc-linux-gnu. (That is what

Re: GCC 4.2.0 RC2 Building

: that will give us a better chance at solving this problem, without introducing new ones. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 RC2 Available

, please download and test the actual tarballs, rather than checking out from SVN tags, in order to help detect packaging problems. If you find a problem, please do not email me directly. Instead, file an issue in Bugzilla: http://gcc.gnu.org/bugzilla/ Thank you, -- Mark Mitchell CodeSourcery

Re: Backport fix for spurious anonymous ns warnings PR29365 to 4.2?

, please find a C++ maintainer who wants to argue for backporting this and ask them to mark the PR as P3 with an argument as to why this is important to backport. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC3 Available

change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 RC3 Available

checkout, match what you see today, with a release tarball? This is in no way a criticism, or a comment on RETMS testing (about which I know almost nothing), etc.; just a general comment, which your message gave me the excuse to make. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: GCC 4.2.0 RC3 Available

Richard Earnshaw wrote: Mark Mitchell wrote: GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing

Re: GCC 4.2.0 RC3 Available

if --disable-checking is in effect? Otherwise, how to do folks like Richard E. that are running natively on small systems work around this issue? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 RC3 Available

actually performs as advertised. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

patch to the 4.2 branch, unless I've warned that I'm doing a final release build. (That's not going to happen imminently; I'm still reviewing the latest lists of nasties.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: MinGW, GCC Vista,

on non-Cygwin Windows. It's reasonable to put this change in libiberty, since it's job is to provide portability between systems. My two cents, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: MinGW, GCC Vista,

Ross Ridge wrote: Mark Mitchell writes: In my opinion, this is a GCC bug: there's no such thing as X_OK on Windows (it's not in the Microsoft headers, or documented by Microsoft as part of the API), and so GCC shouldn't be using it. Strictly speaking, access() (or _access()) isn't

Re: Information about LTO

participants were ever as excited about it. It's certainly not paramount, and Kenny has shown that it's probably more practical just to read/write the IL directly. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-05-11)

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

Re: GCC 4.2.0 Status Report (2007-05-11)

Steven Bosscher wrote: On 5/12/07, Mark Mitchell [EMAIL PROTECTED] wrote: PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Why are you waiting for this one? RTEMS

Re: GCC 4.2.0 Status Report (2007-05-11)

not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

(they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. Names in anonymous namespaces had external linkage for a long time in G++. Did they have internal linkage in 4.1, or was that introduced (in theory) for 4.2? -- Mark

Re: GCC 4.2.0 Status Report (2007-05-11)

Daniel Berlin wrote: On 5/11/07, Mark Mitchell [EMAIL PROTECTED] wrote: Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 31797: An infinite loop in the compiler while building

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? I haven't been; I've been working on the forced unwind stuff, and looking at the rvalue refs patch

Re: GCC 4.2.0 Status Report (2007-05-11)

/bugzilla/show_bug.cgi?id=31586 Maybe someone could solve this, so it is solved in GCC 4.2 and others? Yes, this would be an easy bug to fix, and it would be good to do so, but I don't think this is likely before 4.2.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-05-13)

out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: No, I don't think we know. There's speculation in the PR trail, but that's it. I'd appreciate it if you were able to investigate further, but I think I'd best just accept that this will not be fixed for 4.2.0. Or revert the patch that revealed

GCC 4.2.0 Branch Frozen for Release

As per: http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html Therefore, I'm going to get 4.2.0 out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: I'm concerned about either of the other approaches, in that we don't fully understand why they work, so we can't really be confident we're not just pushing the bug around. Yes. But I would assert that pushing the bug back to where

GCC 4.2 branch open for regression fixes

, please let me know! I'll be sending out a release announcement momentarily. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: ChangeLog === --- ChangeLog (revision 124663) +++ ChangeLog (working copy

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