Re: req. help on merging instructions

Hello! > Iam trying to merge the following two instructions > 1. addu r2, r3,r4 > 2. ld r5 ,mem(r2) # load from address calculated > in the prev. instruction > in to one single isntruction. > 3. ldx r5 , mem(r3(r4)) # indexed load. > I managed to do it with a define_peephole pattern >

Re: About macro: SYMBOL_REF_SMALL_P

[EMAIL PROTECTED] writes: > I'm trying to trace the source code of gcc/mips. > It uses a SYMBOL_REF_SMALL_P macro, > According to the index of 'GNU Compiler Collection Internals', > it should be documented on section RTL representation-Access to Special > Operands but it's not. > How can I find it'

Re: GCC 4.0.1 Status (2005-06-13)

R Hill <[EMAIL PROTECTED]> wrote: > Dan Kegel wrote: (Interestingly, the fixes in glibc-cvs seem to have been made in such a way that the new glibc won't be compilable by older versions of gcc, like gcc-3.4.4. I guess the thinking is that everyone should be using the latest gcc?) Hmm, do you

Re: Porposal: Floating-Point Options

On 2005-06-15, at 06:19, R Hill wrote: Marcin Dalecki wrote: [snip] If you don't have anything constructive to contribute to the discussion then feel free to not participate. If you have objections then voice them appropriately or risk them being dismissed as bullshit baiting. Sorr

req. help on merging instructions

Hello everbody, Iam new to gcc and need some guidance. Iam trying to merge the following two instructions 1. addu r2, r3,r4 2. ld r5 ,mem(r2) # load from address calculated in the prev. instruction in to one single isntruction. 3. ldx r5 , mem(r3(r4)) # indexed load. I managed to do

Re: Bug in transparent union handling?

On Tue, Jun 14, 2005 at 07:59:53PM -0400, Daniel Berlin wrote: > Is this really supposed to look like this? Not really. What's there is Good Enough (tm) if we immediately expand to rtl; the union will Just So Happen to have Pmode, and so things will Just So Happen to work. This needs to use a V

Re: Visual C++ style inline asms

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote: > On Jun 14, 2005, at 9:25 PM, Mike Stump wrote: > >Any objections to adding Visual C++ style inline asms? > > Didn't RTH objected the last time? One has to do a less gross job of it than Red Hat did. I suppose I could be prodded int

Re: Porposal: Floating-Point Options

Marcin Dalecki wrote: [snip] If you don't have anything constructive to contribute to the discussion then feel free to not participate. If you have objections then voice them appropriately or risk them being dismissed as bullshit baiting. --de.

Re: Problems with collect2 on hpux

> > It's not very nice that the shared library list for libstdc++.sl > > includes libgcc_s.sl in the GCC build directory. I believe that the > > HP dynamic loader first looks for it there. If that doesn't work, > > it strips off the basename of the library and tries the dynamic > > search path. >

Re: GCC 4.0.1 Status (2005-06-13)

Daniel Kegel wrote: Scott Robert Ladd wrote: Agreed. I've had mixed reports from folks over in the Gentoo universe about glibc; perhaps this page might be of interest: http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks Hey Scott. That page is pretty outdated. AFAIK we

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:43 PM, Timothy J. Wood wrote: On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote: I think a lot of what happens is that easy bugs do get fixed. The ones that don't are often complex, or ill-reported, and thus tend to require a lot of knowledge to work on effectively.

Re: Porposal: Floating-Point Options

Robert Dewar wrote: Russell Shaw wrote: The original bug was about testing the equality of doubles. I think that's just plain mathematically bad. Error bands should be used to test for "equality", using a band that is in accordance with the minimum precision specified in the compiler documenta

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote: I think a lot of what happens is that easy bugs do get fixed. The ones that don't are often complex, or ill-reported, and thus tend to require a lot of knowledge to work on effectively. One form of mentoring would be to _not_ have the core

RE: Visual C++ style inline asms

>-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >Mike Stump >Sent: Tuesday, June 14, 2005 8:25 PM >To: GCC Mailing List >Subject: Visual C++ style inline asms >Any objections to adding Visual C++ style inline asms? This will greatly help us for those

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Also, it seems you have the wrong belief that, if bug 323 were confirmed in | Bugzilla, a patch would automatically appear. I think the two events are | totally unrelated, especially for an issue which has been debated so much in | the past years, and

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Giovanni Bajo wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > First of all, I would consider polite to CC: me on the mail if you quote and > debate my statements. I meant no offense, and thought that I *had* CC'd you on the message. >>The ISO Standard doesn't prevent GCC from being *bette

PR 14814

Jeff, g++.dg/tree-ssa/pr14814.C has been failing from the first day it was added. It is unclear to me what happened in detail, but in the PR you suggest to XFAIL the testcase. That would be fine: would you please take care of that? Also, notice that there is a typo in the ChangeLog entry for this

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

On Tuesday 14 June 2005 21:17, Daniel Jacobowitz wrote: > Ask me if you want either set of code. Sure, I'd like to take a look at it. > If you want to work on anything without duplicating effort, it behooves > _you_ to discuss it on the mailing lists first. Agreed. I've just recently started l

Re: Visual C++ style inline asms

Mike Stump <[EMAIL PROTECTED]> writes: > Any objections to adding Visual C++ style inline asms? Doesn't that need support to parse assembly? (= essentially a builtin assembler). How else would the compiler know what registers are clobbered and where to put input/output variables? All compilers i

Re: Visual C++ style inline asms

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote: > > On Jun 14, 2005, at 9:25 PM, Mike Stump wrote: > > >Any objections to adding Visual C++ style inline asms? Mike, you're going to get more useful feedback if you ask a question with some details in it. Not all of us use Microsoft

Re: Visual C++ style inline asms

On Jun 14, 2005, at 9:25 PM, Mike Stump wrote: Any objections to adding Visual C++ style inline asms? Didn't RTH objected the last time? -- Pinski

Re: Libstdc++ versioning issues

> What is an ETA for additional information? Am I correct in > understanding, from your previous mail, that these problems occurred in > 4.0.0 as well? Hi Mark. Thanks for your patience. I'm testing a patch that resolves the issue. I expect to have additional details within 24 hrs, and will l

Visual C++ style inline asms

Any objections to adding Visual C++ style inline asms?

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Redirecting off gdb-discuss again] On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote: > On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote: > > better support for inline functions, which is already on the gdb > > roadmap > > Where's the roadmap? I'm just starting to look at this ver

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote: > better support for inline functions, which is already on the gdb > roadmap Where's the roadmap? I'm just starting to look at this very issue and would be good to know what is planned or in progress. Thanks. -Fred

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323, > which was a matter of recent discussion on this list. Some rather > respectable people (e.g., Vincent Lefèvre) consider this a bug, and > have proposed solutions. Yet here's a quo

gcc-3.4-20050614 is now available

Snapshot gcc-3.4-20050614 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050614/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050614 You'll

Bug in transparent union handling?

It seems the structure aliasing patch exposed what appears to be a bug in the C FE. Our docs on transparent union say "@item transparent_union This attribute, attached to a function parameter which is a union, means that the corresponding argument may have the type of any union member, but the arg

Libstdc++ versioning issues

Benjamin -- Right now, the libstdc++ versioning/ABI situation is is all that stands between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation. What is an ETA for additional information? Am I correct in understanding, from your previous mail, that these problems occurred in

Re: Porposal: Floating-Point Options

On 2005-06-14, at 19:29, Russell Shaw wrote: The original bug was about testing the equality of doubles. I think that's just plain mathematically bad. Error bands should be used to test for "equality", using a band that is in accordance with the minimum precision specified in the compiler

Re: Porposal: Floating-Point Options

On 2005-06-14, at 16:32, Scott Robert Ladd wrote: To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct Please define corre

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> I would like to improve floating-point in GCC; doing so scratches my >> personal itch. My silly idea is to determine the best approach >> *through discussion*. > Perfectly appropriate, and you are getting lots of discussion! And I'm burbling with

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: I would like to improve floating-point in GCC; doing so scratches my personal itch. My silly idea is to determine the best approach *through discussion*. Perfectly appropriate, and you are getting lots of discussion!

Re: Porposal: Floating-Point Options

Vincent Lefevre wrote: has little to say about mapping to high level languages, so it is important to understand that appealing to this standard is necessary but far from efficient. Why not efficient? Oops, efficiency on the mind, I meant sufficient :-)

Re: Porposal: Floating-Point Options

Russell Shaw wrote: The original bug was about testing the equality of doubles. I think that's just plain mathematically bad. Error bands should be used to test for "equality", using a band that is in accordance with the minimum precision specified in the compiler documentation. That's often t

mudflap cache question

I just read the mudflap pdf file and wanted to know how the cache was implemented. I looked at the code in mf-runtime.c and found the cache functions. The code for the __mf_uncache_object looks strange to me however. The code looks like: static void __mf_uncache_object (__mf_object_t *old_obj)

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, 2005-06-14 at 09:01 -0700, Mark Mitchell wrote: > CodeSourcery struggles with exactly the same problem; we have worked > hard to set up some test automation for our ARM builds, and it's working > well, but we're not (yet!) as disciplined as we want to be about > analyzing and fixing the

Re: MIPS Tri-arch Question

Eric Christopher wrote: On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote: I just wanted to ask a question about the tri-arch setup for MIPS under IRIX. Is this planned for libraries other than IRIX based shared libraries, will this capability be extended to the linux shared libraries?

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

chris jefferson wrote: > One thing I have come across, both in gcc and in other projects, is that > often discussion is not the best option, but instead just writing some > code is better. There's a fine line between too much talk and not enough. > It's very easy to have discussions go around in

Build success for gcc 3.4.4 on alphaev68-dec-osf5.1 (CompaqTru64UNIX)

HP-Compaq ES45 Successful build of 3.4.3 for alphaev68-dec-osf5.1 (c,c++,f77,objc,ada). [EMAIL PROTECTED]:#gcc -v Reading specs from /usr/local/lib/gcc/alphaev68-dec-osf5.1/3.4.4/specs Configured with: ./configure --host=alphaev68-dec-osf5.1 --prefix=/usr/local --enable-languages=c,c++,f77,objc

Re: Problems with collect2 on hpux

"John David Anglin" <[EMAIL PROTECTED]> wrote on 06/11/2005 12:39:32 PM: > As far as I'm aware, collect2 doesn't strip linker options. You can > see more details about the link process using -Wl,-debug and -Wl,-v. Nope - you are right - collect2 was a red-herring. > It's not very nice tha

Re: MIPS Tri-arch Question

On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote: > I just wanted to ask a question about the tri-arch setup for MIPS under > IRIX. > > Is this planned for libraries other than IRIX based shared libraries, > will this capability be extended to the linux shared libraries? > Short answer: it

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: Richard Guenther wrote: Take a break and come back with results of actual work done, this impresses people a lot more than (repeated) ranting about gcc development in general. I have worked on GCC; not much, and probably trivial in your eyes, but practical wor

Re: A Suggestion for Release Testing

On Jun 14, 2005, at 1:01 AM, Matthew Sachs wrote: And that's why someone (possibly me, ideally someone with more hardware to spare) should do runs against FSF mainline. One thing to watch out is the APPLE LOCAL patches in back-end/code gen area, particularly related to alignment and other

Re: Porposal: Floating-Point Options

On 2005-06-14 13:37:41 -0400, Scott Robert Ladd wrote: > I suppose I need to be consistent... ;) I've said in past threads, > GCC should default to -ansi -std=c99/c++98 -pedantic, and any > deviation should require specification of an option. You're not consistent here. [from the gcc 4.0 man page

Re: Porposal: Floating-Point Options

Robert Dewar wrote: Scott Robert Ladd wrote: To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct This option focuses code ge

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Richard Guenther wrote: > Take a break and come back with results of actual work done, > this impresses people a lot more than (repeated) ranting about > gcc development in general. I have worked on GCC; not much, and probably trivial in your eyes, but practical work nonetheless. To trivialize con

Re: Porposal: Floating-Point Options

Vincent Lefevre wrote: > I don't like the word "correct" here, since the correctness > depends very much on the context. Good point. > I disagree. The default should be a conforming C99 implementation. I suppose I need to be consistent... ;) I've said in past threads, GCC should default to -ansi

RE: strange double comparison results with -O[12] on x86(-32)

Original Message >From: Robert Dewar >Sent: 14 June 2005 00:41 > Dave Korn wrote: > >> ... or it's a bug in the libc/crt-startup, which is where the hardware >> rounding mode is (or should be) set up ... > > Well if you think that the operations should reflect IEEE 64-bit semantics > (

Re: Porposal: Floating-Point Options

Robert Dewar wrote: Scott Robert Ladd wrote: To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct This option focuses code ge

Re: copyright assignment

* James A. Morrison: > The form is here: > http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html > > If you have any questions feel free to ask. It's better to request the current version from the FSF, see:

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On 6/14/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > I wish I could do more, which is why I made (what I hoped were) > constructive suggestions for trying to get more people involved in > fixing bugs. For getting more people involved in fixing bugs they need those bugs in plain C code (read

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Mark Mitchell wrote: > Actually, I don't agree with either of the statements ascribed to me, > and if I conveyed that sentiment, I apologize. And I apologize for perhaps reading more into your statements than was intended. > My point was simply that once you have the tests > and bug reports, some

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, Jun 14, 2005 at 09:01:04AM -0700, Mark Mitchell wrote: > Once I get my automated GCC bug-fixing bot finished I am going to have > an easy life. Unfortunately, I use GCC to build the bot, and I'm > getting an ICE in reload... > I have a patch for that. I'm sure the napking I wrote it o

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: That is exactly my point. Mark chastises people for talking about testing, implying that we are lazy for not providing patches. I don't deny that reality. Mark seems to feel that fixing bugs is as easy as testing and bug reporting, and it is not. Actually, I don't

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: >> If I were to present a patch that implements the recomendations of the >> Numerical C Extensions Group, would it be accepted or rejected (on the >> subject alone; ignore for the moment potential technical bugs in the >> submitted code)? > Again, it would probably be better s

Re: copyright assignment

The form is here: http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html If you have any questions feel free to ask. -- Thanks, Jim http://www.csclub.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim

copyright assignment

I am doing some work on a frontend for gcc. In the process I expect to clean up treelang a little bit. Could you send me the relevant forms? Thanks. Rafael Ávila de Espíndola

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as >> well. I'm not saying that expectation is wrong, I am saying it is an >> impediment to working on GCC. > > with respect, I disagree, and I think you should invest the effort

Re: Porposal: Floating-Point Options

On 2005-06-14 10:52:53 -0400, Robert Dewar wrote: > Scott Robert Ladd wrote: > >-ffp-correct > > > >This option focuses code generation on mathematical correctness, > >portability, and consistency. No 80-bit long doubles, no fsin/fcos, > >making certain that comparison operators work within reason.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: The ISO Standard doesn't prevent GCC from being *better* than specified, does it? Are we somehow breaking ISO compliance by doing math right? Is it so wrong to try and fix a problem that frustrates many people and makes GCC look bad? No, but you are degrading performan

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

On Tue, Jun 14, 2005 at 01:36:13PM +0200, Jan Hubicka wrote: > They exist: > {"code16gcc", set_16bit_gcc_code_flag, CODE_16BIT}, > {"code16", set_code_flag, CODE_16BIT}, > {"code32", set_code_flag, CODE_32BIT}, > {"code64", set_code_flag, CODE_64BIT}, > > but they only switch ASM encoding,

Re: Porposal: Floating-Point Options

On 2005-06-14 10:32:57 -0400, Scott Robert Ladd wrote: > To support different expectations, I suggest defining the following > floating-point options for GCC. This is a conceptual overview; once > there's a consensus the categories, I'll propose something more formal. > > -ffp-correct > > This op

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: the gist of Mark's polite rant? And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as well. I'm not saying that expectation is wrong, I am saying it is an impediment to working on GCC. with respect, I disagree, and I think you should invest the effo

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, Jun 14, 2005 at 10:38:47AM -0400, Andrew Pinski wrote: > > On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote: > > >Andrew Pinski wrote: > >>This is wrong, there is an IRC channel which talks about technical > >>issues > >>deal with developing GCC (not with though but that should be i

Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Redirecting off the misnamed gdb-discuss list; please use [EMAIL PROTECTED] instead.] On Tue, Jun 14, 2005 at 10:22:23AM +0100, Andrew Haley wrote: > You have the same problem with Java -- you're stepping through a Java > program, and all of a sudden you're inside the memory allocator. What > we

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > FreeNode is not the only IRC server. irc.oftc.net is where #gcc is hosted. You are ebing positively rude. Just because I mention FreeNode doesn't mean I'm so ignorant as to be unaware of other servers. Where is irc.oftc.net #gcc above documented? ..Scott

Re: Porposal: Floating-Point Options

Scott Robert Ladd wrote: To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct This option focuses code generation on mathematic

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > > No you don't need to learn a new language. You need to learn RTL which is a > language yes but it is based on LISP. Also some of the recent bugs are on > the tree level so you just need to know GIMPLE which is really just simple > expressions. So I don't see why you are c

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, 14 Jun 2005, Scott Robert Ladd wrote: > If I were to present a patch that implements the recomendations of the > Numerical C Extensions Group, would it be accepted or rejected (on the > subject alone; ignore for the moment potential technical bugs in the > submitted code)? I don't know to

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote: Andrew Pinski wrote: This is wrong, there is an IRC channel which talks about technical issues deal with developing GCC (not with though but that should be in an UNIX/C/C++ IRC channel instead). Where? A Google search on "GCC IRC" does

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > This is wrong, there is an IRC channel which talks about technical issues > deal with developing GCC (not with though but that should be in an > UNIX/C/C++ IRC channel instead). Where? A Google search on "GCC IRC" doesn't find much, and the few times I've visited #gcc on Fr

Porposal: Floating-Point Options

To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct This option focuses code generation on mathematical correctness, portability

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: Gentoo provides a mentoring system for developers. This is far better than GCC's "fix it yourself and send us the code" policy. There is no gentle way to become involved in GCC; it's a sink-or-swim, trial by fire environment. If I could ge

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: Here's an example: Building new targets and fixing some code generation bugs involve changing the machine definitions, which are written in a rather uncommon language. Frankly, I haven't figured out all the nuances yet, mostly because I d

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: For that matter, Gentoo also has some very excellent IRC channels that provide a lot of help, and usually *friendly* help at that. The GCC mailing lists are useful, but there's nowhere to go and have a quick chat about "this is confusing th

Fixing Bugs (Was: A Suggestion for Release Testing)

Mark Mitchell wrote: > I'm all for more testing -- but I have a standard rant about it being > easier to run tests than to fix problems. We actually have a wealth > of known regressions -- some pretty serious -- in Bugzilla, and > plenty more known bugs. Most come from real problems reported by

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

> Richard Henderson <[EMAIL PROTECTED]> writes: > > > On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote: > >> Or, if GAS can be told which mode it should be in via directives in > >> its input (.code32/.code64?), then we could add something like > >> > >> fputs (TARGET_64BIT ? "\t.co

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote: > > Or, if GAS can be told which mode it should be in via directives in > > its input (.code32/.code64?), then we could add something like > > > > fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", > > asm_out_file); > > >

Re: x86 Q: why aren't the SSE intrinsics always_inline?

Stuart Hastings writes: > Subject says it all. > > IIUC, the SSE intrinsics are made available as functions because > that's the least-broken way to support them in a target-agnostic > compiler. They're clearly intended to be fully inlined in normal > usage. And they're marked "inlin

About macro: SYMBOL_REF_SMALL_P

I'm trying to trace the source code of gcc/mips. It uses a SYMBOL_REF_SMALL_P macro, According to the index of 'GNU Compiler Collection Internals', it should be documented on section RTL representation-Access to Special Operands but it's not. How can I find it's document? My english is very po

MIPS Tri-arch Question

I just wanted to ask a question about the tri-arch setup for MIPS under IRIX. Is this planned for libraries other than IRIX based shared libraries, will this capability be extended to the linux shared libraries? -- Jim Gifford [EMAIL PROTECTED] [EMAIL PROTECTED]

Re: A Suggestion for Release Testing

On Jun 13, 2005, at 19:49, Andrew Pinski wrote: On Jun 13, 2005, at 10:36 PM, Matthew Sachs wrote: I've been doing regular builds of Fink against Apple's branch, building our last release alongside our latest engineering build and comparing the two. See: http://cvs.sourceforge.net/vie

Re: Problem with recompute_tree_invarant_for_addr_expr

Hello, > On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote: > > OK, I remembered. I put > > > > if (is_gimple_min_invariant (t)) > > > > or > > > > if (is_gimple_val (t)) > > { > > shortcut; > > } > > > > type constructs on some places in gimplification. > > With an aim t