Re: Proposed semantics for attributes in C++ (and in C?)

Joseph S. Myers wrote: On Sun, 15 Oct 2006, Mark Mitchell wrote: We have a number of C++ PRs open around problems with code like this: struct S { void f(); virtual void g(); }; typedef __attribute__((...)) struct S T; I was happy with the state before r115086 (i.e. with it

Proposed semantics for attributes in C++ (and in C?)

of these restrictions in future, if we add mangling support for attributes.) A variable declaration involving attributes, like: __attribute__((...)) S v; is treated as syntactic sugar for: typedef __attribute__((...)) S T; T v; where T is some invented type name different from all others in the program. For example given: __attribute__((packed)) S v; the type of "&v" is "__attribute__((packed)) S *", and cannot be passed to a function expecting an "S*", but can of course be passed to a function expecting an "__attribute__((packed)) S *", or a typedef for such a type. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: aligned attribute and the new operator (pr/15795)

ify the alignment of memory returned by "operator new", or a GNU attribute that libstdc++ could add to the default declaration (with a system-dependent value, of course), etc. seems fine to me, but I'd be very hesitant to change the ABI proper. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Including GMP/MPFR in GCC repository?

Kaveh R. GHAZI wrote: On Mon, 9 Oct 2006, Mark Mitchell wrote: Kaveh R. GHAZI wrote: Has there been any thought to including GMP/MPFR in the GCC repository like we do for zlib and intl? I do not think we should be including more such packages in the GCC repository. It's complicated fr

Re: java method calls and GIMPLE

ly migrate that to work with LTO. I certainly wouldn't argue that we should wait for LTO to be done to tackle devirtualization. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Including GMP/MPFR in GCC repository?

hat may prevent that. I certainly don't think removing zlib from our repository is the most important improvement we can make to GCC. :-) But, I do think we should resist incorporating more external components into the GCC repository and into its own build process. -- Mark Mitchell CodeS

Re: Including GMP/MPFR in GCC repository?

atements are just my opinions as a GCC developer; they're in no way "official".) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Primary/Secondary Platforms for 4.3

y are widely used platforms. * Remove both Intel and PowerPC Darwin from even secondary status, since the Apple versions of the compiler are sufficiently different from the FSF versions that the FSF versions may not really work well on Apple's released OS. * Keep HPPA HP-UX as primary, or, pe

Re: Darwin as primary platform

to do that release, we'll not worry too much about it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: representation of struct field offsets

_ALIGN, but we could just as well choose to normalize to BITS_PER_UNIT. So long as we can compute the starting offset of the field, why does it matter what the normalization constant is? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 project to merge representation changes

Tom Tromey wrote: Yes, it does. I still haven't deleted the code that uses this, but it will never be invoked. I think that's fine; as long as there are no actual user-visible problems with Java, that shouldn't block merging Sandra/Kazu's changes. -- Mark Mitchell

Re: representation of struct field offsets

bytes could be incorporated into the variably sized offset. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: deprecated functions calling deprecated functions

ense. The person compiling the library should use -Wno-deprecated, and accept that they be calling some other deprecated function they don't intend to call. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 project to merge representation changes

ent, which is better for everyone. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Missing elements in VECTOR_CST

ics, but rather about what I think the internal GCC IR semantics should be. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: IPA branch

hounding reviewers! -- as soon as possible. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Missing elements in VECTOR_CST

Hans-Peter Nilsson wrote: On Mon, 18 Sep 2006, Mark Mitchell wrote: Andrew Pinski wrote: The documention on VECTOR_CST is not clear if we can have missing elements in that the remaining elements are zero. Right we produce such VECTOR_CST for things like: #define vector __attribute__

Re: GCC 4.3 project to merge representation changes

Sandra Loosemore wrote: Mark Mitchell wrote: 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? There are already a bunch of notes about this on the LTO page:

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

Re: IPA branch

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

Re: representation of struct field offsets

han 2^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: representation of struct field offsets

internal 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

work, but I can't see why we should just replace field_byte_offset with a use of byte_position. Does anyone else know? -- 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 suggesti

GCC 4.3 Merge Plan

ze what I think the consensus is for the development list, and then ask for SC ratification. I'd be happy to see both of these projects in GCC 4.3 if all the pieces come together in time. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

IPA branch

root of the IPA branch? Have maintainers with appropriate write 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

Re: Planning for GCC 4.2 branch

at to do when 4.3 Stage 1 starts. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

GCC 4.2 Status Report (2006-09-21)

my plan is to branch 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

Re: GCC 4.3 Platform List

er my 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

Re: GCC 4.3 Platform List

wever, 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

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&

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

GCC 4.3 Platform List

developers as in other systems. 3. Update sparc-sun-solaris2.9 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: 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

Planning for GCC 4.2 branch

x27;t have time 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: Missing elements in VECTOR_CST

till perfectly clear. 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 additio

Re: Merging identical functions in GCC

sample programs. Pick 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: Merging identical functions in GCC

f the argument (i.e,. that "T*" was treated 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: pr27650 - dllimport of virtual methods broken.

27;s called for all methods when the class is complete. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: pr27650 - dllimport of virtual methods broken.

l or in cp_finish_decl. It could be that I'm missing something, though; Danny might want to debate my conclusions. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 4.1 status?

'm sure 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: 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 > &g

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 Wik

GCC 4.3 Projects Page

) we need more time to get 4.3 organized. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

ed by the DWARF 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

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

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

ful for DWARF anyhow -- and, in general, we don't write out 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 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

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

information encoded for the types and decls between the time I write my stuff and when the types 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!!!!

issue. I'm vaguely in favor of that plan, just in that I'm eager to actually see us make something work. On the other hand, building up DWARF reading for this code only to chuck it later does seem wasteful. But, the DWARF reader is already there; it's mostly filling in some blan

GCC 4.2 Status Report (2006-08-22)

tart setting up 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: does gcc support multiple sizes, or not?

;s oddball pointers - could they fit? Maybe so -- but that's another can of worms from a language design point of view... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: does gcc support multiple sizes, or not?

ike to clean up and specify how attributes interact with C++ in more detail, and that might result 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?

x27;s for the C maintainers to say. Since you seem to be hesitant (and, reasonably so, in my opinion!) to work on the language-design issues for C++, 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?

that you still get a constant expression. I understand that this isn't the syntax you write, in that you have to write: static ptr32_t x = __builtin_ptr32 (f); instead of: static void (*far x)() = f; but I think you're much more likely to actually get the built-in approach to wo

Re: does gcc support multiple sizes, or not?

ling a function indirectly, but > that would have 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. -- Ma

Re: does gcc support multiple sizes, or not?

ink you should consider that solution. It's 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?

here's of course no notion of "char *far" or "char *near"; there's just "char *". So, there's no way to directly map your intended type system onto 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?

tatement that we need to specify the semantics is clearly implies that I 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?

crash when the user does something that appears to be legal based on > the gcc manual. Good call. I don't feel qualified to comment for C, but for C++, I think it's correct to say 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?

ther 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 CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: type consistency of gimple

e. I think it's very desirable 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?

ributes, no reason to avoid > target hooks for data attributes. Sure -- but you still have to say what the semantics are! In my opinion, "it seems to work" arguments are far too loose for making semantic changes to the C++ front end. We've been burned too many times. -- 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 [EMAI

Re: does gcc support multiple sizes, or not?

ifferent attributes are the same or different, and if they are different what conversions (if any) can be used to convert back and forth. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: type consistency of gimple

in future. So, I'm not arguing that "whoever gets there first wins", by any means. But, I 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?

assumption is made to be bugs in the front end. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: type consistency of gimple

ions may 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: 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 app

Re: type consistency of gimple

er, in order to get LTO into mainline. So, I guess my inclination would be to just write out the type information now, and thereby avoid the dependency on fixing GIMPLE. -- 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, --

Eric Botcazou appointed RTL maintainer

ase fix PRs and approve patches for same. :-) Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: native or cross libssp?

issues before checking in. These problems are not hard to fix, but sometimes folks that are used to working only in native environments do not think about them. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-07-31)

we need to make 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

Re: A question about ARG_FINAL_P in the Java frontend.

l that > help? Yes. Kazu, I'd suggest you just ignore Java; you can still get proof-of-concept for tree-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

Re: gcc-4.3 projects page?

someone would like to create the page -- if not, I will take care of it shortly. Thanks, -- 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 b

Re: Searching configured and relocated prefix.

ose to spite our face to ship software that doesn't work well and tell users "wait until your system distributor 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.

;. However, you still have the --sysroot command-line option. And, if you're 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.

r their own systems may not be expert administrators; I used to administer my own GNU/Linux box, but I 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.

ve rare while the problems in (1) are relatively common. A lot of users download binary distributions and install 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: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?

common code with function calls. > > Is this the same as Code Factoring? > http://gcc.gnu.org/projects/cfo.html Yes, that's another name. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-07-16)

ons, we'd be under 100. We could do it tomorrow -- and certainly this week! -- with a concerted effort. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [lto] factor code common to all builtin_function

! Yes, I think 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

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

be turned into functions. Then, replace the users of the common code 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: RFD: language hooks in GIMPLE / lang_flag?

is always the type of the LHS. OK. But, GIMPLE is also 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: RFD: language hooks in GIMPLE / lang_flag?

ong" > or vice versa, that cast is not accomplishing anything and *could* be > deleted. In RTL, sure. 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: gcc visibility used by moz

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

Re: RFD: language hooks in GIMPLE / lang_flag?

e 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 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: gcc 4.2 more strict check for "function called through a non-compatible type"

hole in alias > analysis. Yes, users who lie will lose. The only thing we're trying to do here is behave a bit more gracefully. Introducing a call to __builtin_trap is pretty brutal; instead, 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

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 CodeS

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

Andrew Haley wrote: > Mark Mitchell writes: > > > > I also agree with Gaby that we should document this as an extension. If > > we go to the work of putting it back in, we should ensure that it > > continues to work for the foreseeable future. Part of that is w

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

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

Re: A question about TYPE_ARG_TYPES

(...)) is NULL. I'll keep putting gcc_assert > to see what happens. That may be the difference between "void f()" (where TYPE_ARG_TYPES might be NULL) and "void f(...)" (where TREE_VALUE (TYPE_ARG_TYPES) would be NULL). The latter, as Daniel says, is not valid C, but perhaps we used to accept it. -- 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: 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: RFC: __cxa_atexit for mingw32

t -- unless 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

would like to see G++ 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

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