Question about gcc-lib and building on SPARC

ll tree, I have the following directory: $prefix/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3 gcc 3.3.3 was compiled with the following configure flags: [EMAIL PROTECTED] mark]$ gcc -v Reading specs from /cdl/apps/.software/sun/gcc-3.3.3/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3/specs Configured with:

Re: GCC Compiler Engineer job (I am not a recruiter)

Gerald Pfeifer wrote: > On Mon, 10 Apr 2006, Mark Mitchell wrote: >> It seems like we're getting consensus around that approach, despite the >> initial sentiment in the other direction from Mike and Joe. Mike, Joe, >> do either of you care to argue the point? If not,

Re: Question about gcc-lib and building on SPARC

On 12 April 2006 22:18, Mark Cuss wrote: The guy who was here before me set up the previous version (gcc-3.3.3) gcc 3.3.3 was compiled with the following configure flags: configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld --with-ld=/cdl/apps/bin/sun/ld --enable

GCC 4.1 Status Report (2006-04-16)

4.1.1 than by waiting indefinitely. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

"Experimental" features in releases

ould generate a warning, like: warning: -ftree-loop-linear is an experimental feature and is not recommended for production use At least we're ensuring that even someone copying someone else's Makefile is aware that they're in dangerous territory. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "Experimental" features in releases

but I'd still like to have a general strategy for dealing with such options, including the one that would be created to enable the perfect nest conversion code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "Experimental" features in releases

ing: -ftree-loop-linear is an experimental feature and is not >> recommended for production use > > Looks good to me. Good. Independent of this issue, I'd certainly like to get consensus on the general question. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "Experimental" features in releases

Mark Mitchell wrote: I'm going to send two messages to follow up because I think we've got two different topics. This message is about: > In any case, the broader question is: to what extent should we have > experimental options in releases, and how should we warn users of thei

Re: Vector types and type conversions

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

Re: Vector types and type conversions

ame number of elements as the input vector. I suppose that we could introduce these operators into C as well, although the pseudo-template syntax might not be as natural for C users. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Vector types and type conversions

Joe Buck wrote: > On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote: >> Let's accept that both the bit-preserving and value-preserving >> conversions would be useful. How do we differentiate the two? >> >> In C++, we could invent __value_cast and

Re: Vector types and type conversions

Chris Lattner wrote: > > On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote: > >> Let's accept that both the bit-preserving and value-preserving >> conversions would be useful. How do we differentiate the two? >> > >> For vectors, these operators would ap

GCC 4.2 Status Report (2006-04-19)

lease until I have a clearer picture of the functionality situation. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Vector types and type conversions

g Altivec and SPE cast syntax requires that a C-style cast from one vector type to another be bit-preserving. So, we can't change that (or static_casts, which are the kind of C++ cast that are using to implement this kind of C-style cast) without breaking backwards compatibility. -- Mark M

Re: What is the expected behavior of attribute nonnull for C++

The reason I think this is a documentation bug is that (a) it's always been this way, ergo we'd be breaking backwards compatibility to change it, and (b) some of these kinds of attributes could usefully apply to the "this" pointer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What is the expected behavior of attribute nonnull for C++

ULL... It can't be NULL. (There are ways to break your program so that it is in fact NULL, but your program already has undefined behavior at that point.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

ke this difficult. (That's why I assume this suggestion isn't going to be popular.) Assuming people won't accept that restriction, then we ought to either (a) hard-code this choice, or (b) depend on a --enable-* flag. I think it should be considered bad policy to make things work differently for native/cross environments. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Maintainers and new contributions

similar contributions we should clarify that the submitter (or someone else) is willing to be a maintainer, and ask the SC to sign off. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

u can link. (One big-hammer solution there is to revive the "staged install" proposal, where you would do something like "make install DESTDIR=$objdir/install" after building each component, so that Newlib, libgloss, etc., would already be in this staging area, before building libstdc++. I think that would simplify a lot of our Makefiles -- but, of course, necessitate a fair bit of change.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

etc. I think that problem (which we already have in some places) is truly *awful*; whatever short-term win may come out of it for one party is lost in the long-term loss for the whole project when a configuration behaves differently depending on native/cross/Canadian. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

urations, etc. > > I suppose a small case statement could make reasonable guesses about > defaults, too. *-linux* yes, *-elf no, etc. Yes -- so long as whatever procedure we use is unaffected by cross/native/Canadian. (The case statement is what I meant by "hard-coded" answers.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: libstdc++ in a combined tree

It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. In my ideal world, we wouldn't set GCC_NO_EXECUTABLES because we'd be able to link by this point, but I guess it must be there to support exactly the kind

Re: libstdc++ in a combined tree

. If there's already an option, then we've already got one of the solutions I was suggesting. In general, I just want to make sure we don't do things that make cross or Canadian-cross builds behave differently from native compilation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Status of SEE and Autovectorization patches?

w that you reviewed the SEE patches. Is there anything more than needs to be done to get them committed, in your view? Richard, do you think you'll have a chance to look at the autovectorization work soon? If not, is there someone else you might suggest to review it? Thanks, --

Re: Status of SEE and Autovectorization patches?

Roger Sayle wrote: > Hi Mark, > > On Tue, 2 May 2006, Mark Mitchell wrote: >> Roger, I know that you reviewed the SEE patches. Is there anything >> more than needs to be done to get them committed, in your view? > > As far as I'm aware, we're still just wa

Re: Summer of Code project discussion

ollector is that it's a step in the memory pool direction; it's zones can be the things I called pools. Whether we use GC on those pools, or turn the zones into obstacks, or whatever, is a separate step. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Status of SEE and Autovectorization patches?

anything useful on IA32/AMD64, but they should presumably either (a) not cause a bootstrap failure on these architectures, or (b) be disabled on these architectures. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Catching up on lists, release status

I've been implicated in some bugs as well, sadly, and I'll be looking at fixing those, too. If you have information that you feel I should know about, even if duplicative of mail to the list, please feel free to send me a private email to make sure that I'm not missing something cri

Re: mips: -G0 vs __dso_handle

ET_LIBGCC_SDATA_SECTION)) #else #define SDATA_ATTR /* empty */ #endif extern void *__dso_handle SDATA_ATTR; with appropriate documentation in docs/tm.texi, of course. I'll pre-approve that change, but I'll also defer to any other maintainer who has a solution they prefer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A question about your patch for PR c++/26534

Kazu Hirata wrote: > Hi Mark, > > I have a question about your patch for PR c++/26534. > When build_unary_op builds TRUTH_NOT_EXPR, it calls > perform_implicit_conversion to convert p->field to the boolean type. > (FWIW, p->field is expressed as > >). The call

GCC 4.1.1 Status Report (2006-05-15)

/4.2 Regression] wrong code, apparently due to bad VR... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: mips: -G0 vs __dso_handle

DJ Delorie wrote: >> I'll pre-approve that change, but I'll also defer to any other >> maintainer who has a solution they prefer. > > How about this one? OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.1 Status Report (2006-05-15)

Andrew Pinski wrote: > Mark, > >> Therefore, effective midnight tonight (i.e., 12:00AM May 17th in >> California), the 4.1 branch will be frozen. (I previously announced May >> 15th as a target release date.) After that point, all changes, >> including previo

Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning

re. Of course, we have to have a way of knowing if the compiler has dumped a random variable of asm() output into a section, but we must have solved that for section anchors as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: PATCH: Compile options.c with -fcommon

H. J. Lu wrote: > 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> > > * Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o. > (gcc-options.o): New rule. > > * optc-gen.awk: Protect variables for gcc-options.o with > #ifdef GCC_DRIVER/#end

Re: libgcc-math and the gcc 4.2 release

> Another option would be to remove the library only after branching > for 4.2 and only on that branch. I think it's better to remove it from mainline, just so that if there are any build issues we catch them before we branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 branch frozen

I am (finally...) starting the 4.1.1 RC1 build. Please do not check in any changes on the 4.1 branch, even if previous approved. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Imported GNU Classpath 0.91

has been imported now into the libjava directory on the trunk. Please let us know ([EMAIL PROTECTED]) if there are any issues with the new import. Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath

GCC 4.1.1 RC1

%20Status together with any comments you might have about the results. If all goes well, we'll do the official release next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Revert patch for MIPS TImode functions for 4.1.1

t I think that's too big a change to make now. Therefore, Roger, would you please revert your patch? Richard, your patch is OK for 4.1.2, after you feel the mainline version has proven itself. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

Roger Sayle wrote: > Hi Mark and Richard, > > On Fri, 19 May 2006, Mark Mitchell wrote: >> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change >> for MIPS on the GCC 4.1 branch? >> >> (My brain failed to digest the fact that the patch was on 4.1 a

Re: Revert patch for MIPS TImode functions for 4.1.1

Andrew Pinski wrote: > > On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: > >> >> Am I correct PR 22209 is "only" a Fortran problem? This is not a >> rhetorical question; I'm trying to gather data > > No, you can invoke it via using the attribut

Re: Revert patch for MIPS TImode functions for 4.1.1

d let us know whether that option is viable as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

important than shipping a compiler that works with Fortran. Of course, we'd rather not have to choose. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C FE question: Is this test even valid?

ut that's orthogonal to the validity of this test case. Yes, I think the check should be done closer to the FE. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C FE question: Is this test even valid?

Diego Novillo wrote: > Mark Mitchell wrote on 05/19/06 14:54: > >> Yes, this test case is valid; the code is ill-formed GNU C, since the >> machine in question know not have a register named "unknown register". >> ^^

Re: PATCH: Update src/intl from gcc/intl

DJ Delorie wrote: >> I will unless you want to add this to the libiberty merge you do now. > > I don't mind adding it to my script, if people agree that's what they > want. It's just that nobody asked :-P I hereby request that you add automatic intl/ merging

Re: Revert patch for MIPS TImode functions for 4.1.1

Richard Sandiford wrote: > Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf. > Mark, what do you think? I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. So, we could declare that Fortran is not release-cr

Re: Wrong link?

Gerald Pfeifer wrote: > Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to > install this there as well? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

Martin Michlmayr wrote: > * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]: >> I'm a bit torn. On the one hand, it doesn't look like there is any >> other reason to do a 4.1.1 RC2. > > Did anyone investigate those abi_check failures I (and others) ha

Re: Revert patch for MIPS TImode functions for 4.1.1

Mark Mitchell wrote: > Richard Sandiford wrote: > >> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf. >> Mark, what do you think? > > I'm a bit torn. On the one hand, it doesn't look like there is any > other reason to do a 4.1.1 RC2.

LTO Branch

orking on more detailed designs for the various components, and we'll be looking for feedback as we go. -- David Edelsohn Mark Mitchell Diego Novillo Ian Taylor Kenny Zadeck

Re: LTO Branch

down on the public lists since then, >> but the need for link-time optimization hasn't gone away -- so it's time >> to get moving! >> >> We've now created branches/lto in the GCC repository to start doing LTO >> work, beginning with: > > Can you a

Re: GCC 4.1.1 RC1

ings on the web-site gcc-N/changes.html, which highlight important changes. I'd imagine you might want to update bugs.html, in this case? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.1 RC1

DJ Delorie wrote: >> I'd imagine you might want to update bugs.html, in this case? > > Or, perhaps, branch's install.texi's "Host/Target specific > installation notes for GCC" ? Yes, that's probably even better. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

Expansion of __builtin_frame_address

permits FP elimination than the present code. I tend to think that option (iii) might be best, although perhaps it is overkill and option (i) would do. But I'm not entirely sure; still being a gcc novice I have to admit to not being quite thoroughly clear on this myself at this stage. So any

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

Mark Shinwell wrote: > Hi, > > I'd like to gather some opinions and advice on the expansion of > __builtin_frame_address, as discussed on gcc-patches last year [1, 2]. > This centres on the following comment in expand_builtin_return_addr > arising from revision 103294 last

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

I think this is a serious regression, and I would like to consider our options. Daniel has suggested changing the default value 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 i

Re: Expansion of __builtin_frame_address

Mark Mitchell wrote: Mark Shinwell wrote: As for the remaining problem, I suggest that we could: (i) always return the hard frame pointer, and disable FP elimination in the current function; or (iii) ...the same as option (i), but allow targets to define another macro that will cause the

Re: Expansion of __builtin_frame_address

he same way had this glibc backtrace function been noticed last year. This may be a mistaken impression though. Mark

Re: Expansion of __builtin_frame_address

David Edelsohn wrote: Mark Shinwell writes: Mark> If the hard frame pointer is forced by default, then targets which are Mark> particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX. Mark> Since such targets would presumably not have to force reload to keep Mark&g

RE: [patch] Improve loop array prefetch for IA-64

resting case because float loads only access the L2. Thus using "lfetch" for floating point arrays will unnecessarily wipe out the contents of L1. (gcc 3.2.3 only seems to generate "lfetch", which is why I ask...) Thanks, Mark -Original Message- From: Canqun Yang

Re: Expansion of __builtin_frame_address

t; INITIAL_FRAME_ADDRESS_RTX to avoid a penalty. in that I think the default should be working code, and Mark's change accomplishes that. Of course, if _b_f_a(0) can be implemented more efficiently on some target, there should be a hook to do that. And, I think it's reasonable

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

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 a

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

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

dling bug. Do you have a C++ test-case? I'm all 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)

nline operating 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-fi

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

how quickly other things go, those things may or may 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. -

Generator programs can only be built with optimization enabled?

the build objects linked 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?

'xxx'", where 'xxx' matches 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?

Paolo Bonzini wrote: > This was caused by: > 2006-01-22 Zack Weinberg <[EMAIL PROTECTED]> > > * genautomata.c: Include vec.h, not varray.h. > > > The problem that Mark reported happens because (since always) the CFLAGS > of the gcc directory are just

GCC 4.2 Status Report (2006-06-16)

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

Re: state of decimal float support in GCC

the TR will actually be final; things might move again, for all we know. I think you should document the difference, and say that we expect to remove 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

> In a PR Geoff asked if we really want to allow different visibility for > different instantiations. I think we do; perhaps one instantiation is > part of the interface of an exported class, but we want other > instantiations to be generated locally in each shared object. Agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Visibility and C++ Classes/Templates

there's an explicit instantiation elsewhere; you needn't bother implicitly instantiating here". I'm just not comfortable with the idea of #pragmas affecting instantiations. (I'm OK with them affecting specializations, though; in that case, the original template has basical

Re: Visibility and C++ Classes/Templates

people know what to expect. 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

Re: Visibility and C++ Classes/Templates

ybe what we should do 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

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

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

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

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

If the inlining thing is indeed a problem (and I can see how it could be, even though you could not immediately reproduce it), then we should mark the call as uninlinable. Disabling an optimization in the face of such a cast seems more user-friendly than inserting a trap. Since we know the

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

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

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?

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

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?

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

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

<    7   8   9   10   11   12   13   14   15   16   >