Re: __builtin_expect for indirect function calls

; expressable using builtin_expect as-is, at least when it comes > to the syntax? That was my first thought as well. Before we add __builtin_expect_call, I think there needs to be a justification of why this can't be done with __builtin_expect as-is. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Regression count, and how to keep bugs around forever

to work on now. The problem there is that importance is in the eye of the beholder. The PN system expressions something about regressions that's moderately useful, but nothing else. I suspect that we need more database fields, so that people could run more interesting searches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with ARM_DOUBLEWORD_ALIGN on ARM

amount = GEN_INT (offsets->saved_args + saved_regs > - - offsets->outgoing_args); > + + static_chain_size - offsets->outgoing_args); > >insn = emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, > amount)); > -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What is a regression?

Gerald Pfeifer wrote: > On Tue, 23 Oct 2007, Mark Mitchell wrote: >> [...] > > I realized that the documentation we currently have up at > http://gcc.gnu.org/bugs/management.html > was partly incorrect (only listing P1 to P2) and certainly > quite incomplete, so I tried

GCC 4.3.0 Status Report (2008-01-02)

h is progress. So, I think we've moved forward a bit more than the raw numbers might indicate. Previous Report === http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: __builtin_expect for indirect function calls

like: sizeof(__builtin_expect(1, 1)) will change its value. And, the current prototype is documented in the manual. What do people think? Do we have the leeway to change this? Or should we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect? Or...? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: __builtin_expect for indirect function calls

sible. I can't think of a way in which it changes current behavior, unless you call __builtin_expect with a long long, and that's probably not going to do what you expect right now anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

s no sane C++ programmer would do at this point, but we want to support for legacy C++ code. I don't see any a priori problem with changing to match the C front end. We could of course change some of the pedwarns into errors if we really think they ought to be errors. Or, some of them could b

Release Management

d Richard all agreed to help out in this way. Please join me in thanking and congratulating our new co-RMs! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

Joe Buck wrote: > Mark Mitchell wrote: >>> I don't see any a priori problem with changing to match the C front end. >>> We could of course change some of the pedwarns into errors if we really >>> think they ought to be errors. Or, some of them could be ordin

Re: How to stop gcc from not calling noinline functions

g() { f(); } A valid GNU C compiler cannot eliminate the call to "f", as long as the call itself is reachable. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: may_alias attribute and type identity (PR c++/34935)

ions in future, if we add mangling support for attributes. But, yes, if we need to mangle these types, we need to have a mangling for attributes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: may_alias attribute and type identity (PR c++/34935)

nt conversion between them. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: bootstrap broken on mingw

ems. Or, is it the case that the patch to use abs_srcdir means that no matter what Texinfo you have, it's not going to work on MinGW? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

save whatever AltiVec registers its using? Is that what you're suggesting? Daniel, perhaps you can put a full proposal on the table so that we can try to get consensus on thsi? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

erPC ELF ABI group decides what to do with them. It's certainly good to minimize the number of times we introduce ABI changes, so waiting for a definitive plan makes sense. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

're doing and what impact it might have on the various stakeholders. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

David Edelsohn wrote: Mark Mitchell writes: Mark> However, if I understand correct, some users have probably been Mark> implicitly using those options because they were using "-mcpu=970", or Mark> otherwise specifying an AltiVec CPU. It seems desirable in the abstract M

Re: GCC 4.3.0 Status Report (2008-02-14)

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

Re: Double constructors in C++?

of the patches have introduced additional thunks of some kind. Actually giving both names to the same entry point would avoid the ABI problems, and thus be non-controversial. (The ABI explicitly endorses multiple entry points as a solution.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 33

Re: Double constructors in C++?

fully enforced that on all platforms, and if the copies aren't all in the same COMDAT group, then, indeed, I can imagine that you could end up with one of the constructors coming from one place, and one from another -- which might be unfortunate. -- Mark Mitchell CodeSourcery [EMAIL PROT

Re: GCC 4.3 branch created, 4.4 opens for stage1

release branch unless you are also patching all later branches. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: GCC 4.4 criteria - add Fortran as primary language?

t how good of a language Fortran is, or how solid the Fortran front-end is; it's just a comment about usage of GCC. That said, I think that the RMs do -- and should -- pay attention to Fortran. I just think that the statement that only C and C++ regressions are release-critical is importan

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

bout what status Darwin might have in the future; if there's active maintenance -- as, it looks like, there may very well be, given that we have a volunteer for the position -- then that might well reactivate Darwin, even for later 4.3.x releases. Thanks, -- Mark Mitchell CodeSourcery [EMA

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

ug in the use of install-leaf. I didn't mean to imply otherwise. My statement was simply that Darwin-only problems are not in and of themselves release-blockers for 4.3.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

block removing libcall notes by it). Why doesn't it work? Can it be made to work relatively easily? Do we need functionality like this for Ada or Java? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

you've withdrawn the deprecation request, so maybe this is something of a moot point now? I certainly agree that we shouldn't let a non-working feature stand in the way of improvements in 4.4. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

eliminating them before gimplification would be a false negative, so less of a problem. Since this feature is designed to crash your program when it has a bug, crashing your program somewhat less often doesn't make the feature useless; just less useful. -- Mark Mitchell CodeSourcery [

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

when the problems that it causes for darwin are solved)? I think it's important, since, IIUC, it improves our ability to test on all platforms. But, I certainly encourage you to figure out why it breaks Darwin and work out how to fix it! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED]

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

ayout than the eventual installation), making the driver depend on shared libraries created during the build is certainly going to be tricky. In particular, on most platforms LD_LIBRARY_PATH (or equivalent) will have to be set just so whenever xgcc is run. -- Mark Mitchell CodeSourcery [EMAIL

Re: [PATCH][4.3] Deprecate -ftrapv

tions using those codes -- but after gimplification these tree codes are no longer used. 3. Plumb the new operations through the TREE-SSA optimizers, add support for generating the checks during expand for those trapping operations that make it to that point, and disable the insertion of check

Re: Possible GCC 4.3 driver regression caused by your patch

chance yet, but I will try to figure out what's going on soon.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc-4.1-20080303 is now available

e a checkout on the branch from whatever point they prefer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] GCC caret diagnostics

re!" not "Gee, how frustrating, that sometimes works, but often just lies to me." I wouldn't object to having the functionality in the compiler as an option (but off by default), until we fix the accuracy, though. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc-4.1-20080303 is now available

release be made aggressively obvious. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: gcc-4.1-20080303 is now available

have an update release have a new and different license, with which you might not be familiar. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ FE question: When is CLASSTYPE_VBASECLASSES valid?

CLASSTYPE_VBASECLASSES is valid? No; if the class is presently being defined, that will not be set. However, it should be safe to check that for a complete class when !processing_template_decl. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 license in manual still under GPLv2

page? What would be the adverse consequences of just replacing our gpl.texi with the FSF GPLv3 version? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 license in manual still under GPLv2

For something as big and complex as GCC, info/HTML/PDF all seem like better media. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 license in manual still under GPLv2

'd hate to lose them. Well, would anyone like to volunteer to update our manual, then? I think that this is a critical defect in the current sourcebase; do we have a PR open? If not, I can file one. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: vtrelocs: large/modular C++ app speedup ...

an issue; you're not concerned about putting a new application into the field on an old OS, but rather about rolling out a new device with kernel, applications, and all. So, I think we want both options here. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

(buf + len < buf) return 1; return 0; } If you know of a non-GCC compiler that optimizes away the test (so that the function always returns 0), please post here, and let me know the name, version number, command-line options, etc. you used to demonstrate that. Thanks, -- Mark Mitchel

Re: US-CERT Vulnerability Note VU#162289

ew to something like: "Some compilers (including, at least, GCC, PathScale, and xlc) optimize away incorrectly coded checks for overflow. Applications containing these incorrectly coded checks may be vulnerable if compiled with these compilers." ? -- Mark Mitchell CodeSourcery [E

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: "Some compilers (including, at least, GCC, PathScale, and xlc) optimize away incorrectly coded checks for overflow. Applications containing these incorrectly coded checks may be vulnerable if compiled with these compilers." I've now been told that th

Re: US-CERT Vulnerability Note VU#162289

ocusing on GCC exclusively is misleading. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: ICC 10.0 and earlier releases perform the same optimization, but not on straight-line code, such as the testcase. ICC performs the transformation inside loops. Thanks, -- Mark Mitchell Co

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: Apparently, IAR's Atmel AVR compiler does this optimization as well. That CPU has 16-bit addresses, so the tester changed the test case to use "1 << 14" instead of &qu

Re: US-CERT Vulnerability Note VU#162289

has to know that the value of len is non-negative in order to do the optimization. Using an "unsigned int len" parameter should also give it that information, but the version I had was designed to closely resemble the case shown to my by CERT, which used a signed variable. Th

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: Apparently, IAR's Atmel AVR compiler does this optimization as well. That CPU has 16-bit addresses, so the tester changed the test case to use "1 <&l

Re: US-CERT Vulnerability Note VU#162289

n 1; return 0; } which is what the person who emailed me about MSVC tested. I did include the optimization flags they used in that email; they appeared in a comment in the MSVC output. I don't know what those flags mean, though; I'm not an expert on MSVC usage. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: improving auto increment expressions detection across basic blocks.

to do a post-increment -- but is there anything especially clever out there? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: A new meta intrinsic header file for x86 intrinsics

kes it easy for people to move code from icc to GCC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 compilation error

_MAX #endif to host-linux.c. Or some autoconf check that determines whether SSIZE_MAX is available and defines it if it is not, based on the size of size_t. Or something. (I don't know Linux well enough to how consistent these things are across targets.) Thanks, -- Mark Mitchell

Re: RFC: A new meta intrinsic header file for x86 intrinsics

H.J. Lu wrote: Icc and gcc will use the same filename. The question is what filename to use. Oh, OK. If we get to pick, then, yes, I think is nice. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: named address space support

finding out that we have to change them in ways that are not backwards compatible. And, I'd like to know what our C maintainers make of the proposal overall; if they see language issues, then we might want to resolve those with WG14. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: Gerald, There was a report (forwarded by Mark Mitchell) of Microsoft Visual C++ 2005 performing that optimization (the resultant object code was shown). Have you verified that this report was false? both chad and i have tested this with various options on Visual C

Re: US-CERT Vulnerability Note VU#162289

er compilers that do the same optimization. Why is the status for compilers from Microsoft, Intel, IBM, etc. listed as "Unknown" instead of "Vulnerable"? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

g degree to which vitally important software is built with GCC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

e completed that investigation? I can appreciate the desire for an independent investigation, but given the data we have already provided, it should be a pretty simple matter to verify this. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

ata for those people. But, it should be made clear that switching from GCC to icc (or whatever) is not a solution, since many of those compilers also do the optimization. (Never mind the risks that making a major change to your build environment entails...) -- Mark Mitchell CodeSourcery [EMAIL

Re: dg-skip-if on powerpc when multiple cpu cflags specified

CPU with AltiVec support, or something. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

4.3.1 Status Report (2008-04-17)

Status == The GCC 4.3 branch is open for commits under normal release branch rules. GCC 4.3.1 is scheduled for 2008-05-05. As we have not yet built 4.3.1-rc1, we will slip that date. As shown below, there are 2 P1s on the 4.3 branch, so we are not yet ready to build RC1. One of the P1s

Re: dg-skip-if on powerpc when multiple cpu cflags specified

Probably not. Though, I suppose: #if !defined(__PPC405__) asm("haha here is a 405 insn"); #else /* The real test goes here. */ #endif might... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: IRA for GCC 4.4

like the wrong way to go. Vladimir, if you feel that Peter's code cannot be used directly in IRA, would you please explain why not? It does seem like it would be easier for everyone if we could leverage what has already been done. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED]

Re: GCC 4.1 snapshots

pshot-only-if-something-changed, that seems fine too -- but from the FSF point of view 4.1 is now dormant. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [whopr] Design/implementation alternatives for the driver and WPA

ow to start the discussion. == Repackaging == Under this proposal, WPA repackages its input files. FWIW, I'd suggest going this way. I agree that this is probably the way to go in the long term, and avoiding the throw-away stage seems beneficial. -- Mark Mitchell CodeSourcery [EMAIL PROTE

Re: [lto] Streaming out language-specific DECL/TYPEs

cific DECLs and TYPEs after gimplification should be for generating debug information. And if that's already been done, then you shouldn't need it at all. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [tuples] API documentation

like a good idea to me. I agree. And, I think in the source code is the right answer, even over the long term. For one thing, one often needs to know what the API *was* for some old version of GCC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ warnings vs. errors

to finish this project, that would be very much appreciated. We don't want this to be a case where we improved the infrastructure of the compiler -- but made the user experience worse. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.2 Status Report (2008-06-13)

=== http://gcc.gnu.org/ml/gcc/2008-06/msg00155.html The next report for the 4.3 branch will be sent by Joseph. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ warnings vs. errors

Jonathan -- Thanks for pushing this forward! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 On Jun 15, 2008, at 7:06 PM, "Jonathan Wakely" <[EMAIL PROTECTED]> wrote: 2008/6/13 Mark Mitchell: Jonathan Wakely wrote: Hi Volker, thanks for picking th

Re: C++ warnings vs. errors

, DTRT implies not, but should tf_error be changed to tf_warning? I think "DTRT" here means "do what whoever wrote this code thinks the standard should say" not "do what the standard says". Please make these permerrors. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ warnings vs. errors

Jonathan Wakely wrote: 2008/6/18 Mark Mitchell: * I don't think the pedwarn in joust() in cp/call.c should be a permerror, is this a GNU extension? if (warn) { pedwarn ("\ ISO C++ says that these are ambiguous, even \ though the worst conversion for th

Re: C++ warnings vs. errors

Jonathan Wakely wrote: Thanks for the review, here's another patch ... Shall I commit this? Yes, please. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Should we remove java from the default bootstrap languages?

that after-the-fact auto-testing can delivery much of the same value. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Should we remove java from the default bootstrap languages?

articularly if that isn't yielding results -- then we revert? To be clear, I have no special decision-making power here. I'm hoping we can build a consensus to move in this direction, but it has to be a consensus decision. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFC: Bug in specs processing

if the user said "-ofoo.o", and that was missing, we'd delete "foo.o" which we should not. (There is already some code involving have_o_argbuf_index which looks like it may mishandle things like "gcc -c -x c -- -o", but that's another matter.) This idea of going back and looking at argbuf is, therefore, broken by design. I don't see a way to really make %W make sense, in this context. Ideas? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Recent warning regression in libstdc++-v3/libsupc++

then the caller must *add* code to catch the exceptions thrown by callees and raise std::unexpected. So, you want to work bottom-up, putting "throw()" on the leaf functions, and then on callers that call only "throw()" functions and so forth. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Recent warning regression in libstdc++-v3/libsupc++

a future project; it only affects other C++ library implementations, and we don't care so much about that. Does that help? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Bug in specs processing

" spelling, and -- if necessary -- to collapse the spelling for the output. If there really are tools that require "-ofoo.o" this will improve the user experience, since presently saying "-o foo.o" will not work on such platforms. (Because that's true, I doubt

Re: Merging tuples branch into mainline today

y checkins that are already in flight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Merging tuples branch into mainline today

H.J. Lu wrote: Mainline is currently broken on a few platforms: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 I think we should fix it first before another big merge. Diego, what do you think? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Merging tuples branch into mainline today

Diego Novillo wrote: In terms of regressions versus mainline, the only regressions introduced by tuples wrt mainline are the matrix-reorg pass that still has not been converted. Why not fix that before merging, then? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385

Re: Merging tuples branch into mainline today

ld be committed to fixing this pass ASAP after it's checked in; waiting until late August to fix it seems bad. Is there someone else who can commit to working on it as a high priority after the main tuples checkin? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Merging tuples branch into mainline today

Steven Bosscher wrote: If this pass is effectively unmaintained, why not just remove it? Unmaintained passes that are not enabled at any optimization level are usually broken anyway. That's an option, too; the question is whether it has any value. I don't know. -- Mar

Re: Merging tuples branch into mainline today

nk we should be dismissive of "benchmark toy" passes if they actually improve benchmarks significantly. We don't have to like it, but we should accept that people are going to benchmark GCC against its proprietary competition, and that having good benchmark results matters. Thanks,

Re: Merging tuples branch into mainline today

with this? Diego, I think that given Aldy's offer, we can remove this as an issue. Go ahead with the merge, if you're ready. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

to only be a problem for AIX at this point, so that may not be that much of a problem. This is the approach I would suggest. Dump out the debug info for types before you throw away all the information, and then leave it aside. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

te value for the symbol at link time. I'm curious what we do with SRA at the moment. This is the same sort of problem; do we have any solutions at present? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

ld be better than modifying the debugger to make assumptions about magic variable names. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

hat's what everyone is talking about, I think. "Emit" here may also mean "cache in memory some place", rather than "write to a file". It could mean, for example, fill in the data structures we already use for types in dwarf2out.c early, and then throw away th

Re: RFC: Adding non-PIC executable support to MIPS

ot;could I stick a random data byte there and have it affect the function". For example, for a Thumb function whose ISA address is "0x0001", I would consider for size purposes that it starts at "0x", since altering that byte at run-time would change the me

Re: lto gimple types and debug info

non-DWARF debug info. As long as it we design it carefully, there's no reason we should have that limitation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

Kenneth Zadeck wrote: Paolo Bonzini wrote: Mark Mitchell wrote: For that matter, "print sizeof(X)" should print the same value when debugging optimized code as when debugging unoptimized code, even if the compiler has optimized X away to an empty structure! I disagree. sizeof

Re: lto gimple types and debug info

don't escape -- or if the user explicitly tells you that they are. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: lto gimple types and debug info

nt that has that ABI-specified value. If the compiler emits code that behaves differently based on whether I wrote "sizeof (X)" or "12" (assuming X is a 12-byte structure), then the compiler is broken. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

at we need at that point, based only on what we are going to output. (And for DECL_COMDAT things, we should be outputting LTO information only if actually referenced.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

sk. Maybe we should just not write the data out to the LTO file, rather than trying to free it early. If you like, have a free-it-early mode for error-checking (to make sure that we aren't relying on that data) in the same way that we have an always-collect mode for GC (to make sure w

Re: Build requirements for the graphite loop optimization passes

appy if GCC "tricked" me into violating some other license as well. So, if we have a configuration that we know is undistributable, then making me hack the source code to disable the error, or making me use a configure-time override option seems like a good call. Thanks, -- Mark Mitc

GCC 4.4.0 Status Report (2008-08-08)

probably be difficult to fix. Previous Report === http://gcc.gnu.org/ml/gcc/2008-04/msg00539.html Next Report === The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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