GCC 4.1.1 Freeze

I will be building the GCC 4.1.1 release later tonight, or, at latest, tomorrow (Wednesday) in California. Please refrain from all check-ins on the branch until I have announced the release. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.1 Released

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

Re: GCC 4.1.1 Released

Roberto Bagnara wrote: Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC [...] Do you mean a bug-fix release for problems in GCC 4.1.0? Yup. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Expansion of __builtin_frame_address

elsewhere. I will review and approve a suitable patch to implement (iii), assuming that there are no objections from Jim or others. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: IA-64 speculation patches have bad impact on ARM

of the max-sched-extend-regions-iters param to 1. However, I think we should conservatively change it to zero, for now, and then use a target macro to allow IA64 to set it to two, and other ports to gradually turn this on if useful. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: Expansion of __builtin_frame_address

we'd need to work out why that was thought a bad idea before. What option do you suggest? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Expansion of __builtin_frame_address

Richard Sandiford wrote: Mark Mitchell [EMAIL PROTECTED] writes: I'd suggest we leave backtrace() aside, and just talk about __builtin_frame_address(0), which does have well-defined semantics. _b_f_a(0) is currently broken on ARM, and we all agree we should fix it. I don't want to fan

Re: Expansion of __builtin_frame_address

Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind

Re: Expansion of __builtin_frame_address

Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote: Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though

Re: [Bug middle-end/27590] [4.1/4.2 Regression] ICE when compiling catalina.jar from tomcat 5.0.30

for fixing the bug and there's plenty of time to get this into GCC 4.2. So, don't think this means that this bug can't be fixed; it just means I wouldn't hold up the release for it, at this point. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-06-04)

under release-branch rules as of 12:01 AM Wednesday, California time. That will give everyone a few days to check in any in-progress bug-fixes that are not regressions. At this time, I don't think it makes sense to set a 4.2 target branch date. We have to see how fast the bug-fixing goes. -- Mark

Re: GCC 4.2 Status Report (2006-06-04)

not make 4.2. We'll have to take it case by case. The patch queue also includes some patches for bugs that are not strictly speaking regressions. As usual, I think we should permit the inclusion of already submitted patches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Generator programs can only be built with optimization enabled?

into the generator program. I'm using a version of mainline that's a few weeks old; is this something that has been recently fixed? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Generator programs can only be built with optimization enabled?

the optimization options for the current bootstrap phase. That seems unfortunate, but so be it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Generator programs can only be built with optimization enabled?

that include rtl.h should be linked with build/vec.o. That may not be necessary when optimizing, but it would avoid this problem. Do you agree? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-06-16)

-code and ICEs on valid code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: state of decimal float support in GCC

should document the difference, and say that we expect to remove decfloat.h in a future release. I think your other documentation suggestions make sense. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Visibility and C++ Classes/Templates

locally in each shared object. Agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Visibility and C++ Classes/Templates

with the idea of #pragmas affecting instantiations. (I'm OK with them affecting specializations, though; in that case, the original template has basically no impact, so I think it's fine to treat the specialization case as if it were any other function.) -- Mark Mitchell CodeSourcery [EMAIL

Re: Visibility and C++ Classes/Templates

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

Re: unable to detect exception model

Richard Guenther wrote: I'll go ahead and revert the ggc-page.c patch now. Thanks, I think that's the right call. I'm sorry I didn't spot this issue in my review. The idea you have is a good one, but it does look like some of the funny games we're playing get in the way. -- Mark Mitchell

Re: Visibility and C++ Classes/Templates

is try to discourage the use of the #pragma in favor of the attribute? (There are no scoping problems with attributes.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: __cxa_atexit for mingw32

++ support the Microsoft C++ ABI -- unless we can convince Microsoft to support the cross-platform C++ ABI. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: __cxa_atexit for mingw32

Microsoft's patents extend to destruction of global objects with static storage duration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: __cxa_atexit for mingw32

Danny Smith wrote: I have a patch that allows use of atexit for destructors in the same way as __cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next. That sounds great. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A question about TYPE_ARG_TYPES

Daniel Berlin wrote: I believe it also happens with varargs functions in some cases, if there was nothing but a varargs parameter. This is the one and only case in which it should occur, but, yes, it is possible. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A question about TYPE_ARG_TYPES

, but perhaps we used to accept it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc 4.2 more strict check for function called through a non-compatible type

for the foreseeable future. Part of that is writing down what we've decided. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Visibility and C++ Classes/Templates

Jason Merrill wrote: Hmm, I'm starting to be convinced that ignoring #pragma visibility for all template instantiations and specializations will be a simpler rule for users to understand. I think I argued for that earlier; in any case, I agree. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: gcc 4.2 more strict check for function called through a non-compatible type

, we want to say we can't promise this is going to work, but if you want to try, go ahead... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Ben Elliston appointed DFP maintainer

The SC has appointed Ben Elliston as maintainer of the Decimal Floating-Point components of the compiler, including relevant portions of the front ends, libraries, etc. Ben, please update MAINTAINERS to reflect your expanded role. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650

Re: RFD: language hooks in GIMPLE / lang_flag?

{ int i; } and struct T {int j; } are not the same type. So, what should happen is that the front end should make these differences/similarities visible to the middle end via TYPE_ALIAS_SET, or some other mechanism *in the IL itself* rather than via a callback. -- Mark Mitchell CodeSourcery [EMAIL

Re: gcc visibility used by moz

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

Re: RFD: language hooks in GIMPLE / lang_flag?

. In GIMPLE, I don't think so, as if you do that you lose the type information about the result. But, I'm not a GIMPLE expert; maybe there's some magic way of handling this. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

supposed to be type-safe, so I wouldn't think that int = long would be well-formed gimple. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?

with function calls. If we wanted to do this in GCC, it might well make sense to do this at the same place we presently do inlining. Some toolchains do it in the linker, at the level of assembly code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [lto] factor code common to all builtin_function

that would be good. However, we can also wait until it goes into the mainline, and until we decide to merge the mainline to LTO. I don't think we need it on the LTO branch on this time. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-07-16)

this week! -- with a concerted effort. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?

Factoring? http://gcc.gnu.org/projects/cfo.html Yes, that's another name. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Searching configured and relocated prefix.

them somewhere convenient; relatively few try to do complicated things involving partially shared installations, and those users are probably more expert. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Searching configured and relocated prefix.

didn't know about most of the options to the kernel or other parts of the system. And, many GCC users are running on Windows, where they have less control. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Searching configured and relocated prefix.

worried about Windows, see Paul's response; the problems I've described are particularly bad on Windows, and the developer-base there is often less used to GNU software, so the problems are even weirder. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Searching configured and relocated prefix.

fixes your OS. Even for most GNU/Linux users, that would be untenable; they're not system hackers, and they only get to upgrade when RHEL or SuSE or Debian or ... distributes new packages. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Searching configured and relocated prefix.

Andrew Pinski wrote: On Jul 23, 2006, at 11:48 AM, Mark Mitchell wrote: Are you suggesting that we ship software that performs poorly on one of the most popular systems actually in the field because, in the abstract, those systems could be better? Maybe we just have to force the issue

Re: gcc-4.3 projects page?

the page -- if not, I will take care of it shortly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A question about ARG_FINAL_P in the Java frontend.

-trimming without Java. The ECJ changes are going to be massive, and they're going to go in before we get our stuff ready to go in, so dealing with Java now is probably a waste of time; we'll have to regroup after ECJ goes in. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-07-31)

some headway on 4.2 first. So, I think we're still in a holding pattern: let's get the P1s fixed. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Eric Botcazou appointed RTL maintainer

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

Re: Eric Botcazou appointed RTL maintainer

Eric Botcazou wrote: Obvious question: what of the RTL expander(s)? They're specifically excluded from your purview. (That's not a judgment on your competence; just that the definition we used when discussing your appointment restricted itself to RTL passes only.) Thanks, -- Mark Mitchell

Re: type consistency of gimple

the type information now, and thereby avoid the dependency on fixing GIMPLE. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: type consistency of gimple

Daniel Berlin wrote: Mark Mitchell wrote: Kenneth Zadeck wrote: So, I guess my inclination would be to just write out the type information now, and thereby avoid the dependency on fixing GIMPLE. Please don't take this the wrong way, but this approach is the reason GIMPLE is not flat

Re: type consistency of gimple

be implicit, and what the semantics of those conversions are. The question of where exactly to let implicit conversions occur can be driven by space considerations and convenience. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

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

Re: type consistency of gimple

don't think we can ignore the motivations of contributors, either; we've got to accept that they'll invest time/effort/money in GCC only to the extent they see return on that investment. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

what conversions (if any) can be used to convert back and forth. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

Andrew Pinski wrote: Aren't there some targets (like ia64-hpux) that support two different sizes of pointers Those are entirely separate ABIs, controlled by a command-line option. There are not multiple pointer sizes within any single program. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: does gcc support multiple sizes, or not?

burned too many times. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: type consistency of gimple

for the type-checker to be a separate pass so that we can run it at various points in the compilation to check for consistency; that will help us isolate problems. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

almost every other such change has lead to trouble, I'm not inclined to take chances. Please do the work up front to specify how this interacts with all aspects of the language. That's user documentation we need anyhow. I do think this sounds like a useful feature. Thanks, -- Mark Mitchell

Re: does gcc support multiple sizes, or not?

that we don't support them. I think we *could* support them, in theory, but that would be a good bit of work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

don't think it's a useful feature? I do think it's a useful feature, but I also think that you can't just drop it into C++ without thinking about all the consequences of that action. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

the conversion sequence above. The spirit of the standard would seem to be that X* near - X* far - X* near be value-preserving, but to make no guarantees about X* far - X* near - X* far. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

not as pretty, for the programmer, but it's a lot less problematic from a language point of view. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

to be specific to the target, and documented therein. Again, a built-in will work here. If you avoid trying to introduce multiple *pointer* types, and just treat these things as *integer* types, you avoid all of the hard language issues. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: does gcc support multiple sizes, or not?

++, I would recommend the integer approach as a way of providing the functionality you need in the short term. Sorry, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

in problems for this usage. (We really need to specify how attributes interact with same-typed-ness, implicit conversions, etc.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

-- but that's another can of worms from a language design point of view... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-08-22)

the 4.3 process soon, so that we're ready to go before the 4.2 release branch is created. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

reader is already there; it's mostly filling in some blanks. But, filling in blanks is always harder than one expects. So, I think this should really be your call: rework the format now, or later, as you think best. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

and decls are written. I'm not sure what this means. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

Daniel Berlin wrote: On 8/31/06, Kenneth Zadeck [EMAIL PROTECTED] wrote: Mark Mitchell wrote: Kenneth Zadeck wrote: Even if we decide that we are going to process all of the functions in one file at one time, we still have to have access to the functions that are going to be inlined

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

information about types/declarations that are entirely unused. The key aspects (sizes/layouts/etc.) are fixed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

Daniel Jacobowitz wrote: On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote: Here, we won't be making syscalls Yes, you almost certainly will. OK, good point. In any case, my concern is that we're worrying a lot about on-disk encoding, but that there are lots of other hard

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

standard. I think this is probably moot, since I believe that Kenny feels DWARF is not suitable for reasons other than the abbreviation table issue, but this is a clever technique. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3 Projects Page

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

Re: GCC 4.3 Projects Page

Joe Buck wrote: On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote: Please add your project page to the bottom of: http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning BTW, that page provides a link to SampleProjectPage which does not exist. Thanks! I forgot which Wiki syntax I

Re: GCC 4.3 Projects Page

Daniel Berlin wrote: On 9/1/06, Mark Mitchell [EMAIL PROTECTED] wrote: Joe Buck wrote: On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote: Please add your project page to the bottom of: http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning BTW, that page provides a link

Re: 4.1 status?

that, a priori, people would prefer a 4.1.2 release, but it does take effort. On the other hand, many 4.1 bugs are also in 4.2. Any thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pr27650 - dllimport of virtual methods broken.

something, though; Danny might want to debate my conclusions. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pr27650 - dllimport of virtual methods broken.

methods when the class is complete. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Merging identical functions in GCC

the same, independent of T). I think that *all* of these places might be useful eventually: in the front end, the back end, and the linker. I'd be happy to start anywhere. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Merging identical functions in GCC

a random application (maybe an KDE office application?) and measure how many functions, if any, in the final link image are duplicates. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Missing elements in VECTOR_CST

. This is why PR 29091 is failing currently. output_constant assumes VECTOR_CST have the correct number of elements but the C front-end via digest_init creates a VECTOR_CST with only 2 elements. Thus, I think that output_constant should be changed to add the additional zeros. -- Mark Mitchell

Planning for GCC 4.2 branch

to get me input today. I will revise both the branch date and 4.3 staging in response to feedback; consider today's expected mail as a first try. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pr27650 - dllimport of virtual methods broken.

Danny Smith wrote: cp/ChangeLog PR target/27650 * class.c (check_for_override): Remove dllimport from virtual methods. testsuite/Changelog PR target/27650 * g++.dg/ext/dllimport12.C: New file. OK, thanks. -- Mark Mitchell CodeSourcery [EMAIL

GCC 4.3 Platform List

to sparc64-sun-solaris2.10? 4. Replace powerpc-apple-darwin with i686-apple-darwin. Apple's hardware switch would seem to make the PowerPC variant less interesting. 5. Add i686-mingw32 as a secondary platform. Reactions? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 Platform List

Mark Mitchell wrote: My proposed changes: 1. Replace arm-none-elf with arm-none-eabi. Most of the ARM community has switched to using the EABI. 2. Downgrade hppa2.0w-hp-hpux11.11 and powerpc-ibm-aix5.2.0.0 to secondary platforms. Update HP-UX to 11.31? Update AIX to 5.3? I like having

Re: GCC 4.3 Platform List

Andrew Pinski wrote: On Wed, 2006-09-20 at 23:11 -0400, Mark Mitchell wrote: Reactions? Change powerpc-unknown-linux-gnu to powerpc64-unknown-linux-gnu so that we also require the 64bit of PowerPC to work. To be clear, you're suggesting that we say powerpc64-unknown-linux-gnu, but mean

Re: GCC 4.3 Platform List

, the fact that there are no test results coming in does seem consistent with your suggestion. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 Platform List

initial flurry of postings, not to respond directly -- I don't want to dominate the discussion. So, I'll just say that I think that's a perfectly reasonable suggestion, and step back. In a few days, I'll try to put together a summary of the opinions of the group. -- Mark Mitchell

GCC 4.2 Status Report (2006-09-21)

as soon as we get to 100, but no sooner that September 28th. Please fix what you can; let's get this show on the road! (I'll send a separate mail about 4.3 -- but I may not be able to do that before tomorrow morning, as I want to spend some time thinking about all the projects.) Thanks, -- Mark

ARM Thumb-2 merge?

Paul -- In addition to the Thumb-2 bits, I assume you plan to merge the other ARM changes on the branch? Is that correct? (For example, what about the NEON bits?) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

IPA branch

privileges reviewed the patches? I'm not in any way trying to send a negative signal about this work. I have every hope that it will be merged soon. I just want to better understand the situation. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3 Merge Plan

of these projects in GCC 4.3 if all the pieces come together in time. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 Platform List

Mark Mitchell wrote: I have now reviewed the suggestions. Here is the mail that I plan to recommend to the SC. (Of course, I can't guarantee what the SC will do with it.) I've tried to take into account most of the feedback. However, I've tried to note all of these suggestions in my draft

Re: representation of struct field offsets

field_byte_offset with a use of byte_position. Does anyone else know? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: representation of struct field offsets

representation of integers, you have to be careful that you have enough bits; for example, you need 72 bits to represent things in a 64-bit address space. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: representation of struct field offsets

^61 ? I'm not sure -- but if it doesn't, it should. There are folks who like to make structures corresponding to the entire address space, and then poke at particular bytes by using fields. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: IPA branch

are fixed. Is there a project page for this work? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3 project to merge representation changes

Kazu, Sandra -- I don't believe there is a GCC 4.3 project page to merge the work that you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please create a Wiki page for that? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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