Re: Import GCC 4.2.0 PRs
On 3/12/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Here are some GCC 4.2.0 P1s which I think it would be good for GCC to > have resolved before the release, together with names of people I'd like > to volunteer to help. (Naturally, I have no command authority, and I'd > encourage anyone else who wants to help to pitch in, but I'm trying to > tap a few likely suspects.) > > * PR 29585 (Berlin) -- This is a crash in alias analysis with anonymous > namespaces. I can't imagine that anonymous namespaces have any deep > implications for aliasing, so I would hope this is an easy fix. The bug report says that part is fixed, and only a ccp issue remains. "The testcase in comment #2 works for me on the 4.2 branch now, but the one in comment #7 fails with ... in tree-ssa-ccp.c" Yes, this is a similar issue as PR30840 on the mainline, the CCP propagator goes up the lattice in some cases. This is something Diego promised me to look at ;) But we might be able to paper over this issue in 4.2 ... Richard.
On INTEGER_CST
Hello all, INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields (tree.def). Each has 32 bits. 1 - Should I use ints for these fields? 2 - If the INTEGER_CST is negative, is the negative part only in one of the high or low fields, i.e. low is always unsigned and high is always signed? If not, how do I know if the constant is signed or unsigned? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
On NULL and 0
Hello, When programming, due to my journeys through C++ recently, I've been using 0 instead of NULL. Strangely gcc compilation doesn't warn me about it. Is it ok to do this? (So far, I had no problems). Is there anything I should be aware when using 0 instead of NULL in gcc code? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RE: On NULL and 0
On 13 March 2007 13:52, Paulo J. Matos wrote: > Hello, > > When programming, due to my journeys through C++ recently, I've been > using 0 instead of NULL. Strangely gcc compilation doesn't warn me > about it. Is it ok to do this? (So far, I had no problems). Is there > anything I should be aware when using 0 instead of NULL in gcc code? Nope. (This is really a gcc-help@ question, but anyway) Zero is completely acceptable for a null pointer constant in all circumstances *except* when passing to a varargs function, which can go badly wrong on platforms where the sizeof a pointer is larger than the sizeof an int. See the gnu coding standards, which mentions this. cheers, DaveK -- Can't think of a witty .sigline today
Question for removing trailing whitespaces (not vertical tab) from source
Hello, I want to remove some trailing whitespaces from gcc source as coding style demands. Also I wrote, while doing a small tool for that, a feature to replace horiz. tabs by spaces. But the question is by which width should be used ? The gcc source was written by using different tab widths :( May somebody can give me an advice. Regards, i.A. Kai Tietz Kai Tietz - Software engineering OneVision Software Entwicklungs GmbH & Co KG Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany Phone: +49-941-78004-0 FAX: +49-941-78004-489 WWW: http://www.OneVision.com
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz writes: > I want to remove some trailing whitespaces from gcc source as coding style > demands. Also I wrote, while doing a small tool for that, a feature to > replace horiz. tabs by spaces. But the question is by which width should > be used ? 8. Andrew.
For those using emacs ...
... a little tip. Add this to your c-mode-hook: (set-variable 'show-trailing-whitespace t) And you'll see all the trailing whitespace. On my system it appears bright red. Andrew.
Re: For those using emacs ...
On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote: > ... a little tip. Add this to your c-mode-hook: > >(set-variable 'show-trailing-whitespace t) > > And you'll see all the trailing whitespace. On my system it appears > bright red. > Doesn't seem to work on xemacs :( Andrew Walrond
Re: On INTEGER_CST
"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH > fields (tree.def). Each has 32 bits. No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64 bits. > 1 - Should I use ints for these fields? I don't understand the question. > 2 - If the INTEGER_CST is negative, is the negative part only in one > of the high or low fields, i.e. low is always unsigned and high is > always signed? If not, how do I know if the constant is signed or > unsigned? Negative numbers are sign extended through both the high and low fields. That said, you need to look at the type of the constant to know whether you have a negative number or a very large positive number. Ian
Re: Question for removing trailing whitespaces (not vertical tab) from source
Andrew Haley <[EMAIL PROTECTED]> writes: > Kai Tietz writes: > > > I want to remove some trailing whitespaces from gcc source as coding style > > demands. Also I wrote, while doing a small tool for that, a feature to > > replace horiz. tabs by spaces. But the question is by which width should > > be used ? > > 8. But please do not turn tabs into spaces in the gcc source code. I think removing trailing whitespace would be OK, although it does tend to obscure svn blame. I wonder if we could have some sort of svn trigger to check for trailing whitespace as a pre-commit check on .c and .h files? Ian
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 14:02, Andrew Haley wrote: > Kai Tietz writes: > > > I want to remove some trailing whitespaces from gcc source as coding > style > demands. Also I wrote, while doing a small tool for that, a > feature to > replace horiz. tabs by spaces. But the question is by which > width should > be used ? > > 8. > > Andrew. Can you explain that value? It's just that 1) I see vast acres and acres of code where the tabstop size is two spaces 2) the coding standard doesn't seem to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind of depths of nesting the gcc code often contains we're going to exceed the 80-column line length limit just on the leading indentation alone pretty often cheers, DaveK -- Can't think of a witty .sigline today
Re: For those using emacs ...
On 3/13/07, Andrew Walrond <[EMAIL PROTECTED]> wrote: Doesn't seem to work on xemacs :( xemacs != emacs Anyways I was going to say: Don't But now we are getting into emacs vs vi vs xemacs which is getting offtopic. -- Pinski
Re: Question for removing trailing whitespaces (not vertical tab) from source
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Kai Tietz writes: > > > > > I want to remove some trailing whitespaces from gcc source as coding > > style > > > demands. Also I wrote, while doing a small tool for that, a feature to > > > replace horiz. tabs by spaces. But the question is by which width > > should > > > be used ? > > > > 8. > > But please do not turn tabs into spaces in the gcc source code. > > I think removing trailing whitespace would be OK, Please don't check it in, though! That would be really bad. It would do horrible things to diffs, particularly between branches. Andrew.
RE: Question for removing trailing whitespaces (not vertical tab) from source
Dave Korn writes: > On 13 March 2007 14:02, Andrew Haley wrote: > > > Kai Tietz writes: > > > > > I want to remove some trailing whitespaces from gcc source as coding > > style > demands. Also I wrote, while doing a small tool for that, a > > feature to > replace horiz. tabs by spaces. But the question is by which > > width should > be used ? > > > > 8. > > > Can you explain that value? It's just that 1) I see vast acres and acres > of > code where the tabstop size is two spaces 2) the coding standard doesn't seem > to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind > of > depths of nesting the gcc code often contains we're going to exceed the > 80-column line length limit just on the leading indentation alone pretty > often That's not the question I answered, which was "when I come across a leading tab character in GNU souce code, how many spaces does that tab represent?" It says nothing about correct GNU indentation, which is two spaces. Andrew.
Re: Question for removing trailing whitespaces (not vertical tab) from source
On 3/13/07, Andrew Haley <[EMAIL PROTECTED]> wrote: Dave Korn writes: > On 13 March 2007 14:02, Andrew Haley wrote: > > > Kai Tietz writes: > > > > > I want to remove some trailing whitespaces from gcc source as coding > > style > demands. Also I wrote, while doing a small tool for that, a > > feature to > replace horiz. tabs by spaces. But the question is by which > > width should > be used ? > > > > 8. > > > Can you explain that value? It's just that 1) I see vast acres and acres of > code where the tabstop size is two spaces 2) the coding standard doesn't seem > to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind of > depths of nesting the gcc code often contains we're going to exceed the > 80-column line length limit just on the leading indentation alone pretty > often That's not the question I answered, which was "when I come across a leading tab character in GNU souce code, how many spaces does that tab represent?" It says nothing about correct GNU indentation, which is two spaces. A tab is 8 spaces. Always. Richard.
Re: On NULL and 0
On 3/13/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 13 March 2007 13:52, Paulo J. Matos wrote: > Hello, > > When programming, due to my journeys through C++ recently, I've been > using 0 instead of NULL. Strangely gcc compilation doesn't warn me > about it. Is it ok to do this? (So far, I had no problems). Is there > anything I should be aware when using 0 instead of NULL in gcc code? Nope. (This is really a gcc-help@ question, but anyway) Zero is completely acceptable for a null pointer constant in all circumstances *except* when passing to a varargs function, which can go badly wrong on platforms where the sizeof a pointer is larger than the sizeof an int. See the gnu coding standards, which mentions this. Thank you, I only posted here because it was about standard coding in gcc code. But should read the gnu coding standards indeed. Always forget gcc is GNU. :) cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: On INTEGER_CST
On 13 Mar 2007 07:58:41 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Paulo J. Matos" <[EMAIL PROTECTED]> writes: > INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH > fields (tree.def). Each has 32 bits. No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64 bits. > 1 - Should I use ints for these fields? I don't understand the question. Which C type is HOST_WIDE_INT? > 2 - If the INTEGER_CST is negative, is the negative part only in one > of the high or low fields, i.e. low is always unsigned and high is > always signed? If not, how do I know if the constant is signed or > unsigned? Negative numbers are sign extended through both the high and low fields. That said, you need to look at the type of the constant to know whether you have a negative number or a very large positive number. Isn't the type of the constant always integer_type? How can I know if it is negative or positive? Ian Thank you, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Question for removing trailing whitespaces (not vertical tab) from source
> Kai Tietz writes: > Also I wrote, while doing a small tool for that, a > feature to replace horiz. tabs by spaces. But the question is by which > width should be used ? Tabs always are equivalent to 8 spaces. But please DO NOT replace tabs in the GCC sources with spaces. Eight spaces should be tabs. Thanks, David
Compiling without the use of static registers in IA-64
All- I was wondering if anyone knew how I could modify gcc to not use static general purpose registers on an IA-64 machine? Specifically, I only want the compiler to allocate registers from the register stack engine (RSE) and the system defined registers (e.g., stack pointer, global pointer, etc). I do not want to allocate general purpose registers 2-11 or 14-31. Any ideas? Thanks, Chad Rosier ps. please reply to my email address as well as the mailing list as I'm not currently subscribing to the list. :( Thanks!
Re: Question for removing trailing whitespaces (not vertical tab) from source
Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57: > Ian Lance Taylor writes: > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > Kai Tietz writes: > > > > > > > I want to remove some trailing whitespaces from gcc source > as coding style > > > > demands. Also I wrote, while doing a small tool for that, a > feature to > > > > replace horiz. tabs by spaces. But the question is by which > width should > > > > be used ? > > > > > > 8. > > > > But please do not turn tabs into spaces in the gcc source code. > > > > I think removing trailing whitespace would be OK, > > Please don't check it in, though! That would be really bad. It would > do horrible things to diffs, particularly between branches. > > Andrew. > But I was questioned to do this stuff, for those files changed by a patch of mine. So I tought, if I should do, than do it for the complete gcc (not root) folder. How to process ? Kai
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 15:06, Andrew Haley wrote: > Dave Korn writes: > > On 13 March 2007 14:02, Andrew Haley wrote: > > > > > Kai Tietz writes: > > > > > > > I want to remove some trailing whitespaces from gcc source as coding > > > style > demands. Also I wrote, while doing a small tool for that, a > > > feature to > replace horiz. tabs by spaces. But the question is by > which > > width should > be used ? > > > > > > 8. > > > > > > Can you explain that value? It's just that 1) I see vast acres and > acres of > code where the tabstop size is two spaces 2) the coding > standard doesn't seem > to /demand/ a specific tab size and 3) if we use > 8-space TABs with the kind of > depths of nesting the gcc code often > contains we're going to exceed the > 80-column line length limit just on > the leading indentation alone pretty > often > > That's not the question I answered, which was "when I come across a > leading tab character in GNU souce code, how many spaces does that tab > represent?" It says nothing about correct GNU indentation, which is > two spaces. Thanks for clarification, the false inference I was making was that a TAB was (or could be) equivalent to an indent level. (Sometimes it is, of course - I guess a lot of the mixed-formatting problems probably arise where a chunk of code that used to be at one indent level that happened to be a multiple of 4 and hence could be aligned using TABs gets moved to a different context where they would need to be converted to spaces and adjusted...) cheers, DaveK -- Can't think of a witty .sigline today
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz writes: > Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57: > > > Ian Lance Taylor writes: > > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > > > Kai Tietz writes: > > > > > > > > > I want to remove some trailing whitespaces from gcc > > > > > source as coding style demands. Also I wrote, while doing > > > > > a small tool for that, a feature to replace horiz. tabs > > > > > by spaces. But the question is by which width should be > > > > > used ? > > > > > > > > 8. > > > > > > But please do not turn tabs into spaces in the gcc source code. > > > > > > I think removing trailing whitespace would be OK, > > > > Please don't check it in, though! That would be really bad. It would > > do horrible things to diffs, particularly between branches. > > But I was questioned to do this stuff, for those files changed by a patch > of mine. So I tought, if I should do, than do it for the complete gcc (not > root) folder. How to process ? Feel free to do it to your local copy. Don't do it to the gcc source code repository. Andrew.
Re: Compiling without the use of static registers in IA-64
[EMAIL PROTECTED] wrote: All- I was wondering if anyone knew how I could modify gcc to not use static general purpose registers on an IA-64 machine? Specifically, I only want the compiler to allocate registers from the register stack engine (RSE) and the system defined registers (e.g., stack pointer, global pointer, etc). I do not want to allocate general purpose registers 2-11 or 14-31. Any ideas? Thanks, Chad Rosier ps. please reply to my email address as well as the mailing list as I'm not currently subscribing to the list. :( Thanks! It is better ask such things on gcc-help. You can use -ffixed-REG option to prevent allocation of such registers or change FIXED_REGISTERS macro in ia64.h.
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote: > Feel free to do it to your local copy. Don't do it to the gcc source > code repository. Well, please do it on all your checkings - all lines you have changed to fix some bug or add a new feature shouldn't have trailing whitespace and in the leading whitespace should use tabs instead of 8 spaces. But please don't change lines that wouldn't be otherwise touched just to change their formatting. Jakub
Re: On NULL and 0
> Zero is completely acceptable for a null pointer constant in all > circumstances *except* when passing to a varargs function, which can go > badly wrong on platforms where the sizeof a pointer is larger than the > sizeof an int. This is a serious loophole on such platforms, since the compiler cannot diagnose the error. (The "sentinel" attribute covers only one special case.) Our approach has been to ask compiler vendors to widen such integer arguments to intptr_t (or uintptr_t), which is happily doable since the vendors are already passing `int' arguments in intptr-wide registers or stack slots. A couple vendors only gave us a secret option for this, we are now asking them to enable the option by default :-) This is also a problem when passing to a function whose prototype is not in scope. (Compilers can issue a diagnostic for that, but they should also widen in such cases as well.) Tom Truscott
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz <[EMAIL PROTECTED]> writes: > But I was questioned to do this stuff, for those files changed by a patch > of mine. So I tought, if I should do, than do it for the complete gcc (not > root) folder. How to process ? I don't feel as strongly as Andrew about not removing trailing whitespace, but in any case the way to proceed seems clear: do it for your patch but not for gcc as a whole. Ian
Re: On INTEGER_CST
"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > On 13 Mar 2007 07:58:41 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64 > > bits. > > > > > 1 - Should I use ints for these fields? > > > > I don't understand the question. > > > > Which C type is HOST_WIDE_INT? It's host dependent (hence the name). See gcc/hwint.h. > Isn't the type of the constant always integer_type? How can I know if > it is negative or positive? No, the type of the constant, by which I mean the type as seen by the program being compiled, can be any integral type. In particular it can be an unsigned type. You need to look at TREE_TYPE. Ian
Re: Question for removing trailing whitespaces (not vertical tab) from source
Jakub Jelinek <[EMAIL PROTECTED]> wrote on 13.03.2007 16:37:34: > On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote: > > Feel free to do it to your local copy. Don't do it to the gcc source > > code repository. > > Well, please do it on all your checkings - all lines you have changed > to fix some bug or add a new feature shouldn't have trailing whitespace > and in the leading whitespace should use tabs instead of 8 spaces. > But please don't change lines that wouldn't be otherwise touched just > to change their formatting. > >Jakub > Ok, I will try for this. I have to find a different editor, which is not too smart as to remove trailing whitespaces ... Cheers, Kai
Re: Question for removing trailing whitespaces (not vertical tab) from source
Ian Lance Taylor writes: > I wonder if we could have some sort of svn trigger to check for > trailing whitespace as a pre-commit check on .c and .h files? It would be tricky, as we don't want it to barf on spaces that already were there. The emacs magic works very well for me: I'm sure that I have checked in no trailing spaces since enabling it. Andrew.
Re: On INTEGER_CST
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: Which C type is HOST_WIDE_INT? It can either be long, or long long depending on if the target needs it to be 64bits and what size of long on the host. Isn't the type of the constant always integer_type? No, it can be POINTER_TYPE, ENUMERAL_TYPE or OFFSET_TYPE (and INTEGER_TYPE). How can I know if it is negative or positive? You can use tree_int_cst_sign_bit or tree_int_cst_msb depending on the context. -- Pinski
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Tue, Mar 13, 2007 at 03:02:44PM -, Dave Korn wrote: > Can you explain that value? It's just that 1) I see vast acres and acres of > code where the tabstop size is two spaces 2) the coding standard doesn't seem > to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind of > depths of nesting the gcc code often contains we're going to exceed the > 80-column line length limit just on the leading indentation alone pretty > often GCC indents with tabs replacing eight leading spaces but an indentation depth of two spaces. I don't know where your acres and acres are, but they aren't in most GNU software. This is, unsurprisingly, how emacs behaves. Personally I think that regardless of your indentation preferences, using anything besides eight column tab stops for \t is silly; that's what "cat" is going to use. -- Daniel Jacobowitz CodeSourcery
Re: Updating libtool in GCC and srctree
On Mon, Mar 12, 2007 at 04:03:52PM -0700, Steve Ellcey wrote: > configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl Where'd that come from? Wherever it is, it's a bug. Maybe someone checked in a typo to the configure file. "dnl" is a comment start token in autoconf (that's a very rough approximation of the situation). > I am not sure why I get this, nothing else seems to be requiring > m4_pattern_allow. If I don't use any -I options on aclocal it works and > then I get a different error from autoconf (about TL_AC_GXX_INCLUDE_DIR > being possibly undefined). I think I want the -I options though. Yes, you always want to match ACLOCAL_AMFLAGS from Makefile.am. -- Daniel Jacobowitz CodeSourcery
Re: PATCH: make_relative_prefix oddity
On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote: > It treats only "/opt" as a common component of the two paths, rathe > than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for > the last argument, the answer is as I expected. This seems odd to me; > is it the intended behavior? > > The patch below (which is against an older version of libiberty, and > might need updating) fixes it. Assuming you agree that this is a bug, > would this patch (with updating and testing) be OK? I believe that at the time your patch was first written, we decided to fix this in the driver instead and leave make_relative_prefix unchanged: 2006-04-28 Joseph S. Myers <[EMAIL PROTECTED]> * gcc.c (process_command): Add program name to GCC_EXEC_PREFIX value before passing to make_relative_prefix. -- Daniel Jacobowitz CodeSourcery
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 15:12, Daniel Jacobowitz wrote: > On Tue, Mar 13, 2007 at 03:02:44PM -, Dave Korn wrote: >> Can you explain that value? It's just that 1) I see vast acres and >> acres of code where the tabstop size is two spaces 2) the coding standard >> doesn't seem to /demand/ a specific tab size and 3) if we use 8-space TABs >> with the kind of depths of nesting the gcc code often contains we're going >> to exceed the 80-column line length limit just on the leading indentation >> alone pretty often > > GCC indents with tabs replacing eight leading spaces but an indentation > depth of two spaces. I don't know where your acres and acres are, > but they aren't in most GNU software. Yeh, as explained, I was conflating tabstops with indents, sorry. > Personally I think that regardless of your indentation preferences, > using anything besides eight column tab stops for \t is silly; that's > what "cat" is going to use. Well, I always *used* to think of a tab stop as being unequivocally and universally equal to 8 columns too, but that was a long time ago and since then bitmapped displays and WYSIWYG editors have come into being ... Anyway. The presence of the word "preferences" indicates to me that this thread is liable to decay into an OT bikeshed debate if we keep it up, so I'm dropping it now! :-) cheers, DaveK -- Can't think of a witty .sigline today
Re: For those using emacs ...
Andrew Walrond <[EMAIL PROTECTED]> writes:
> On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
>> ... a little tip. Add this to your c-mode-hook:
>>
>>(set-variable 'show-trailing-whitespace t)
>>
>> And you'll see all the trailing whitespace. On my system it appears
>> bright red.
>>
>
> Doesn't seem to work on xemacs :(
That's what I use in XEmacs:
(require 'cc-mode)
(require 'cc-fonts)
(if (find-face 'font-lock-trailing-spaces-face)
()
(make-face 'font-lock-trailing-spaces-face)
(add-spec-list-to-specifier (face-property 'font-lock-trailing-spaces-face
'background) '((global (nil . "grey60") ((grayscale) . "gray80") ((color) .
"gray"
(add-spec-list-to-specifier (face-property 'font-lock-trailing-spaces-face
'reverse) '((global ((tty) . t
)
(setq
my-add-keywords
'(("\\([ ]+$\\)" (1 font-lock-trailing-spaces-face prepend
(setq
c-font-lock-keywords-1
(append
c-font-lock-keywords-1
my-add-keywords))
(setq
c-font-lock-keywords-2
(append
c-font-lock-keywords-2
my-add-keywords))
(setq
c-font-lock-keywords-3
(append
c-font-lock-keywords-3
my-add-keywords))
-- Sergei.
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Mar 13, 2007, at 8:01 AM, Ian Lance Taylor wrote: Andrew Haley <[EMAIL PROTECTED]> writes: I think removing trailing whitespace would be OK Generally speaking, yes, but be aware, there are cases where it should not be removed. To most, the spots that should not be changed are obvious, once you see them. If you just blindly did it with an emacs automatic rule, in time, it would do the wrong thing.
RTL representations and virtual addresses
Hello, I use -da to dump RTL files of the passes. Is there a way to add the virtual addresses of each directive ? I know that RTL is abstraction and virtual addresses are relevant only when the actual opcodes are generated. My wish is to generate a CFG in which I would know, for each basic block and RTL command, what is the virtual address this command will be at in the binary.. Thank You Very Much, sunzir.
Re: Import GCC 4.2.0 PRs
Richard Guenther wrote on 03/13/07 05:57: > Yes, this is a similar issue as PR30840 on the mainline, the CCP propagator > goes > up the lattice in some cases. This is something Diego promised me to look at > ;) > But we might be able to paper over this issue in 4.2 ... I'll take a look later this week.
Re: PATCH: make_relative_prefix oddity
Daniel Jacobowitz wrote: > On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote: >> It treats only "/opt" as a common component of the two paths, rathe >> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for >> the last argument, the answer is as I expected. This seems odd to me; >> is it the intended behavior? >> >> The patch below (which is against an older version of libiberty, and >> might need updating) fixes it. Assuming you agree that this is a bug, >> would this patch (with updating and testing) be OK? > > I believe that at the time your patch was first written, we decided to > fix this in the driver instead and leave make_relative_prefix > unchanged: > > 2006-04-28 Joseph S. Myers <[EMAIL PROTECTED]> > > * gcc.c (process_command): Add program name to GCC_EXEC_PREFIX > value before passing to make_relative_prefix. No, this is a different issue. That patch was about the first argument to make_relative_prefix (the "program_name" argument). This patch (which is shiny and new as of yesterday) is about the second and third arguments. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Question for removing trailing whitespaces (not vertical tab) from source
> -Original Message- > From: Dave Korn [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 13, 2007 9:59 AM > To: 'Daniel Jacobowitz' > Cc: 'Andrew Haley'; 'Kai Tietz'; gcc@gcc.gnu.org > Subject: RE: Question for removing trailing whitespaces (not > vertical tab) from source > > On 13 March 2007 15:12, Daniel Jacobowitz wrote: > > > Personally I think that regardless of your indentation preferences, > > using anything besides eight column tab stops for \t is > silly; that's > > what "cat" is going to use. > > Well, I always *used* to think of a tab stop as being > unequivocally and > universally equal to 8 columns too, but that was a long time > ago and since > then bitmapped displays and WYSIWYG editors have come into being ... At the risk of extending this out further, can someone explain to me why using TABs is preferrable, as they are interpreted, while spaces are unambiguous? Not everyone uses emacs, vi, , or even GNU/Linux... Eric
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Tue, Mar 13, 2007 at 10:31:34AM -0600, Eric Weddington wrote: > At the risk of extending this out further, can someone explain to me why > using TABs is preferrable, as they are interpreted, while spaces are > unambiguous? If anyone wants to explain this to Eric, please do so off-list. Let's not tie up this list with a long off-topic discussion.
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Mar 13, 2007, at 9:31 AM, Eric Weddington wrote: At the risk of extending this out further, can someone explain to me why using TABs is preferrable That is just how to the world is.
Referenced Vars in IPA pass
Hi all,
In #gcc, it was suggested to use referenced vars to get all the
referenced vars for a function. I added to my IPA pass props,
PROP_referenced_vars , used push_cfun and then
FOR_EACH_REFERENCED_VAR, however, it just segfaults in
tree-flow-inline.h:34 :
hti->slot = table->entries;
It was said gimple was lowered and referenced vars created before IPA
passes but I guess not due to the segfault. :(
Is there a way to get the referenced vars?
This was all due to the fact that I wished to get a list of
referenced vars in my pass, so I was going through all the basic
blocks and statements, then found out that...
int x;
{
int y;
{
int z;
...
}
...
}
just happens to have three statements, all VAR_DECL,x, y, z, without
any reference to the starting and ending blocks. As a side question,
how can I get hand of where the blocks start and finish? Don't really
know if it's useful but If I need it later, better I know how.
Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Referenced Vars in IPA pass
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.
This is not available anymore after lowering to GIMPLE. BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.
Paolo
Re: Referenced Vars in IPA pass
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.
This is not available anymore after lowering to GIMPLE. BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.
So, I guess I should not worry about nested blocks. But then again,
why do I get a segfault?
Paolo
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Referenced Vars in IPA pass
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.
This is not available anymore after lowering to GIMPLE. BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.
Ah, by the way, I'm not using trunk, I'm using stable 4.1 code.
Paolo
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Referenced Vars in IPA pass
On Tue, 2007-03-13 at 18:09 +0100, Paolo Bonzini wrote:
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x, y, z, without
> > any reference to the starting and ending blocks. As a side question,
> > how can I get hand of where the blocks start and finish? Don't really
> > know if it's useful but If I need it later, better I know how.
>
> This is not available anymore after lowering to GIMPLE. BIND_EXPRs
> (representing lexical scope) are removed in gimple-low.c.
Correct. FWIW, we originally kept that BIND_EXPRs and a variety of
other higher level constructs. But they turned out to be a major
PITA to work with in the optimizers. It was far cleaner to flatten
the IL.
Jeff
Re: Referenced Vars in IPA pass
On 3/13/07, Jeffrey Law <[EMAIL PROTECTED]> wrote:
On Tue, 2007-03-13 at 18:09 +0100, Paolo Bonzini wrote:
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x, y, z, without
> > any reference to the starting and ending blocks. As a side question,
> > how can I get hand of where the blocks start and finish? Don't really
> > know if it's useful but If I need it later, better I know how.
>
> This is not available anymore after lowering to GIMPLE. BIND_EXPRs
> (representing lexical scope) are removed in gimple-low.c.
Correct. FWIW, we originally kept that BIND_EXPRs and a variety of
other higher level constructs. But they turned out to be a major
PITA to work with in the optimizers. It was far cleaner to flatten
the IL.
OK, thank you.
Jeff
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Referenced Vars in IPA pass
Uh, since when did 4.1 support IPA GIMPLE?
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x, y, z, without
> > any reference to the starting and ending blocks. As a side question,
> > how can I get hand of where the blocks start and finish? Don't really
> > know if it's useful but If I need it later, better I know how.
>
> This is not available anymore after lowering to GIMPLE. BIND_EXPRs
> (representing lexical scope) are removed in gimple-low.c.
>
Ah, by the way, I'm not using trunk, I'm using stable 4.1 code.
> Paolo
>
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Referenced Vars in IPA pass
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: Uh, since when did 4.1 support IPA GIMPLE? What do you mean by that? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Referenced Vars in IPA pass
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Uh, since when did 4.1 support IPA GIMPLE? > > What do you mean by that? I'm pretty sure there were a number of cgraph and other related changes necessary to make IPA work completely that were first in 4.2. I may be misremembering though, Jan?
Re: Referenced Vars in IPA pass
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: > On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > Uh, since when did 4.1 support IPA GIMPLE? > > > > > > What do you mean by that? I'm pretty sure there were a number of cgraph and other related changes necessary to make IPA work completely that were first in 4.2. I may be misremembering though, Jan? No, you are right. Paulo, you should be working off the trunk really. Richard.
Re: Question for removing trailing whitespaces (not vertical tab) from source
Kai Tietz wrote: > Ok, I will try for this. I have to find a different editor, which is not > too smart as to remove trailing whitespaces ... Or just add -w to the diff options when generating the patch. Brian
Re: Referenced Vars in IPA pass
On 3/13/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: > > On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > Uh, since when did 4.1 support IPA GIMPLE? > > > > > > > > > > What do you mean by that? > > I'm pretty sure there were a number of cgraph and other related > changes necessary to make IPA work completely that were first in 4.2. > > I may be misremembering though, Jan? No, you are right. Paulo, you should be working off the trunk really. Richard. Argh, those are really bad news... :( My initial choice for stable 4.1 was that I didn't know _anything_ about gcc internals and since my work is involved with my PhD research I didn't want to mess with gcc internal problems (which may come up in trunk code) since problems with my phd are enough. Now I'm really not knowing what to do. Should I really work on trunk or 4.2 is better to stay off nasty problems? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RFH: G++ manual page in GCC 4.2.0
My attempt to build GCC 4.2.0 RC1 failed with: cp doc/gcc.1 doc/g++.1 cp: cannot stat `doc/gcc.1': No such file or directory This is coming from the G++ Make-lang.in, which does: doc/g++.1: doc/gcc.1 cp doc/gcc.1 doc/g++.1 However, when we --enable-generated-files-in-srcdir (as we do for releaes), doc/gcc.1 is in the source directory. VPATH finds it, so the dependency is satisfied, but the copy doesn't work. I intend to fix this by changing the rule to be: cp $< doc/g++.1 which will resolve VPATH correctly. Does anyone see a problem with this plan? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Updating libtool in GCC and srctree
> On Mon, Mar 12, 2007 at 04:03:52PM -0700, Steve Ellcey wrote:
> > configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl
>
> Where'd that come from? Wherever it is, it's a bug. Maybe someone
> checked in a typo to the configure file. "dnl" is a comment start
> token in autoconf (that's a very rough approximation of the situation).
It looks like it is coming from the new libtool.m4, I just sent email to
bug-libtool@gnu.org about it. In the new libtool.m4 there is:
# LT_PROG_GCJ
# ---
AC_DEFUN([LT_PROG_GCJ],
[m4_ifdef([AC_PROG_GCJ], [AC_PROG_GCJ],
[m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
[AC_CHECK_TOOL(GCJ, gcj,)
test "x${GCJFLAGS+set}" = xset || GCJFLAGS="-g -O2"
AC_SUBST(GCJFLAGS)])])dnl
])
And I think the dnl at the end of the AC_SUBST line is the problem.
Removing it seems to fix the configure of libjava anyway.
> Yes, you always want to match ACLOCAL_AMFLAGS from Makefile.am.
Now that is a very useful thing to know.
I am trying to build now and am currently running into a problem building
libgfortran.
When doing the libtool link of the library I get:
ld: Can't find library or mismatched ABI for -lgfortranbegin
Fatal error.
collect2: ld returned 1 exit status
make[3]: *** [libgfortran.la] Error 1
I was able to build libstdc++-v3 and other libraries with no problem,
but I haven't figured out what is going on here yet.
Steve Ellcey
[EMAIL PROTECTED]
Re: RFH: G++ manual page in GCC 4.2.0
On 3/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: My attempt to build GCC 4.2.0 RC1 failed with: cp doc/gcc.1 doc/g++.1 cp: cannot stat `doc/gcc.1': No such file or directory This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899 yes, yes I have bugzilla memorized. -- Pinski
XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
When I try mayalias-2.x like so:
set torture_eval_before_execute {
global compiler_conditional_xfail_data
set compiler_conditional_xfail_data {
"PR 28834" \
{ "*-*-*" } \
{ "-O3" } \
{ "" }
}
}
return 0
I get
XPASS: gcc.c-torture/execute/mayalias-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal
compiler error)
That is, I am getting an unintended XPASS for
-O3 fomit-frame-pointer. Also, the "-O3 -g" one doesn't show XFAIL
even though the options do contain -O3.
How do I make gcc.c-torture/execute/mayalias-2.c XFAIL on -O3 -g?
Thanks,
Kazu Hirata
How to hide registers from local RA but not reload?
Hello Gcc hackers, I don't even know if what I'm doing is supposed to be possible, but I'm trying it anyway! To oversimplify the situation, I've got an external memory-mapped peripheral that does multiply operations. It's got three SImode registers; you write a word each to the multiplier and multiplicand, and a few cycles later you read back the result from the result register. So my first idea to make this work is to treat each of the peripheral's memory locations as if they were actually hard regs. My strategy is - allocate hard reg numbers to each of these registers - define a reg class for each of these registers, with a single member in each, corresponding to the given (fake) hard register. - define md constraint letters for each of these classes. - implement the mulsi3 pattern, accepting only register operands and using the constraint letter on each operand that corresponds to the relevant hard(ware) register. - implement movsi3 alternatives to move between a general register and each of the single-member reg classes (these are actually memory load/stores in disguise as reg-reg moves). - allow reload to take care of moving the operands for mulsi3 insns into the relevant pseudo-hardregs by using the movsi3 patterns. However, the last thing I want is for the register allocater to decide it's a good idea to ever allocate one of these registers for general usage, because they're really memory locations; using one to store a pseudo would be basically the same as spilling it to the stack. Trying to mark them as FIXED_REGs didn't work, as it meant reload didn't even think it could use them, so I settled for leaving them unFIXED, but not mentioning them in the REG_ALLOC_ORDER. This initially appeared to have the desired effect; at any rate, it generated correct assembly code for mulsi3 operations. But it has had some undesirable knock-on effects; it perturbs the lreg pass in a bad way. The intermediate cause is that lreg considers all the special-purpose reg classes when allocating, and for some reason decides that several of the special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I find strange about this is that it then decides to take the highest-numbered class as the preferred register class, despite the fact that it has a lot less members in it than GENERAL_REGS. (There is no overlap between the classes, so I haven't put them in the "wrong order", as one is not a subset of the other). Anyway, somehow this preference throws things off, and it *looks* like it ends up assuming it needs yet another register to reload into the specialised class reg, and then it eliminates the original register and the overall effect is that instead of allocating a consecutive bunch of hard regs starting with my volatile arg-passing regs, it leaves gaps in the range and allocates further registers beyond the end of it, so a routine that previously got allocated r1 to r6 (r1-r4 are function arg-passing regs in this setup) might end up using r1 to r5 and r7. Which leads to one or two questions: Q. Is it possible to do what I really want: to make the compiler aware of some registers, but limit their usage to a single insn; to allow reload to use these registers when directed to by a constraint letter, but for the rest of the compiler to basically pretend they don't even exist. Q. Would it perhaps work better if I didn't rely on reload to move args into the specialised registers, but used an expander or splitter to generate the sequence of store operand 1 to multiplier register, store operand 2 to multiplicand register, load operand zero from result register? I wouldn't need to mess around with register classes at all, but I might have problems controlling the scheduling and sequencing of the operations - you have to load the two input registers in the correct order, since loading the second one triggers the operation. Q. Or should I just adjust the costs of these registers to something ludicrous, so that they would never ever seem to be preferable to any other register nor even a memory spill, and not worry about whether it thinks they are allocatable or not? cheers, DaveK -- Can't think of a witty .sigline today
Re: Error in checking compat.exp
On Tue, Mar 13, 2007 at 09:13:14AM +0200, Revital1 Eres wrote: > > Hello, > > I get the following error while running > make check-gcc RUNTESTFLAGS="compat.exp" > with mainline gcc version 4.3.0 20070312 > on PPC. > ERROR: tcl error sourcing > /home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp. > ERROR: couldn't open > "/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C": > no such file or directory I assume that /home/eres/mve_mainline_zero_12_3/gcc is your source tree; does the file exist? If not, I don't know what could be wrong but can investigate. Janis
Re: How to hide registers from local RA but not reload?
"Dave Korn" <[EMAIL PROTECTED]> writes: > The intermediate cause is that lreg considers all the special-purpose reg > classes when allocating, and for some reason decides that several of the > special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I > find strange about this is that it then decides to take the highest-numbered > class as the preferred register class, despite the fact that it has a lot less > members in it than GENERAL_REGS. (There is no overlap between the classes, so > I haven't put them in the "wrong order", as one is not a subset of the other). Did you set REGISTER_MOVE_COST for your new registers? > Q. Is it possible to do what I really want: to make the compiler aware of > some registers, but limit their usage to a single insn; to allow reload to use > these registers when directed to by a constraint letter, but for the rest of > the compiler to basically pretend they don't even exist. This is more or less what the MIPS backend does with the HI and LO registers. You might want to look at that. Ian
RE: How to hide registers from local RA but not reload?
On 13 March 2007 19:56, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> The intermediate cause is that lreg considers all the special-purpose reg >> classes when allocating, and for some reason decides that several of the >> special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I >> find strange about this is that it then decides to take the >> highest-numbered class as the preferred register class, despite the fact >> that it has a lot less members in it than GENERAL_REGS. (There is no >> overlap between the classes, so I haven't put them in the "wrong order", >> as one is not a subset of the other). > > Did you set REGISTER_MOVE_COST for your new registers? Ah, no I didn't. Having said that, do I really want to? At the moment I have no definition of it at all, so everything has the default cost 2. Isn't this right? I want to use reloads to get the input operands from gprs into the memory-mapped registers, and I have defined movsi3 patterns to exchange between any of the specialised registers and the gprs, and I'm not sure in what way you're suggesting I should uuse REGISTER_MOVE_COST. >> Q. Is it possible to do what I really want: to make the compiler aware of >> some registers, but limit their usage to a single insn; to allow reload to >> use these registers when directed to by a constraint letter, but for the >> rest of the compiler to basically pretend they don't even exist. > > This is more or less what the MIPS backend does with the HI and LO > registers. You might want to look at that. Thanks Ian, that sounds very much like what I'm looking for, I'll take a dig through it. cheers, DaveK -- Can't think of a witty .sigline today
Re: Question for removing trailing whitespaces (not vertical tab) from source
Andrew Haley wrote: > I think removing trailing whitespace would be OK, Please don't check it in, though! That would be really bad. It would do horrible things to diffs, particularly between branches. Not if you run the script on all active branches. Not to say it is worth it, though. Cheers, Pedro Alves
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote: Hi Janis, While PR 28834 stays open, I'm thinking about XFAILing gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g. However, I am not having any luck with writing mayalias-2.x. I am wondering if you could help me with XFAIL. There is no way to xfail testcases which fail because of ICEs. This was decided to go this way so people won't start xfailing them. -- Pinski
Re: Error in checking compat.exp
Revital1 Eres wrote: ERROR: tcl error sourcing /home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp. ERROR: couldn't open "/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C": Note that mainline got changed to xline. Also note that the directory has files bitfield_main.C, bitfield_x.C, and bitfield_y.C. So it looks like there is a tcl script somewhere to replace "main" with "x", which fails if the directory path contains "main" anywhere in it other than in the filename at the end. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Compiling without the use of static registers in IA-64
[EMAIL PROTECTED] wrote: I was wondering if anyone knew how I could modify gcc to not use static general purpose registers on an IA-64 machine? Besides the -ffixed-reg option Vlad mentioned, there is also a documented IA-64 specific option for this. See the docs. No reason why this option needs to be IA-64 specific though; it was just implemented that way for convenience before the IA-64 port was contributed to the FSF. You may have trouble with 64-bit constants if you disable r2/r3. There are only four regs that work with the addl instruction, and you have just disallowed all of them. You might need other changes to make this work. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Tue, Mar 13, 2007 at 12:28:22PM -0700, Kazu Hirata wrote:
> Hi Janis,
>
> While PR 28834 stays open, I'm thinking about XFAILing
> gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
> However, I am not having any luck with writing mayalias-2.x. I am
> wondering if you could help me with XFAIL.
>
> When I try mayalias-2.x like so:
>
> set torture_eval_before_execute {
> global compiler_conditional_xfail_data
> set compiler_conditional_xfail_data {
> "PR 28834" \
> { "*-*-*" } \
> { "-O3" } \
> { "" }
> }
> }
> return 0
>
> I get
>
> XPASS: gcc.c-torture/execute/mayalias-2.c execution, -O3
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal
> compiler error)
>
> That is, I am getting an unintended XPASS for
> -O3 fomit-frame-pointer. Also, the "-O3 -g" one doesn't show XFAIL
> even though the options do contain -O3.
>
> How do I make gcc.c-torture/execute/mayalias-2.c XFAIL on -O3 -g?
You want the XFAIL to apply to compilation, not execution, and only for
"-O3 -g", not for all uses of -O3. This one works (surprisingly, because
as Andrew said it's usually not possible to XFAIL an ICE).
set torture_eval_before_compile {
set compiler_conditional_xfail_data {
"PR 28834" { "*-*-*" } { "-O3 -g" } { "" }
}
}
return 0
Janis
Re: RTL representations and virtual addresses
Sunzir Deepur wrote: I use -da to dump RTL files of the passes. Is there a way to add the virtual addresses of each directive ? You can't compute addresses reliably until after reload. Before reload, the size of each rtl insn is unknown. My wish is to generate a CFG in which I would know, for each basic block and RTL command, what is the virtual address this command will be at in the binary.. You can already find much of this info in the gcov profiling files. See profile.c and gcov.c and other related files. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Error in checking compat.exp
On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote: > Revital1 Eres wrote: > >ERROR: tcl error sourcing > >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp. > >ERROR: couldn't open > >"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C": > > Note that mainline got changed to xline. Also note that the directory > has files bitfield_main.C, bitfield_x.C, and bitfield_y.C. > > So it looks like there is a tcl script somewhere to replace "main" with > "x", which fails if the directory path contains "main" anywhere in it > other than in the filename at the end. That is indeed the problem; testsuite/lib/compat.exp contains # Set up the names of the other source files. regsub "_main.*" $src1 "" base regsub ".*/" $base "" base regsub "_main" $src1 "_x" src2 regsub "_main" $src1 "_y" src3 I'll find a way to fix that. Janis
new gcc 4.2 testsuite failures on powerpc-apple-darwin8
The current gcc 4.2 branch is exhibiting some new testsuite failures in the gcc testsuite on powerpc-apple-darwin8. Specifically I now see... Running /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/vmx.exp ... FAIL: gcc.dg/vmx/dct.c -O0 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O1 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O2 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/dct.c -Os (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O0 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O1 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O2 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/fft.c -Os (test for excess errors) which all seem to fail as follows... Executing on host: /sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/ /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c -O0 -maltivec -mabi=altivec -std=gnu99 -fno-show-colu mn -S -m32 -o dct.s(timeout = 300) /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: C99 inline functions are not supported; using GNU89 /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute output is: /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: C99 inline functions are not supported; using GNU89 /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute FAIL: gcc.dg/vmx/dct.c -O0 (test for excess errors) Any idea why we are the only target seeing these failures with gcc 4.2 branch? Jack
Re: new gcc 4.2 testsuite failures on powerpc-apple-darwin8
Jack Howarth <[EMAIL PROTECTED]> writes: > The current gcc 4.2 branch is exhibiting some new > testsuite failures in the gcc testsuite on powerpc-apple-darwin8. > /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: > warning: C99 inline functions are not supported; using > GNU89 > /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: > warning: to disable this warning use -fgnu89-inline or > the gnu_inline function attribute > > FAIL: gcc.dg/vmx/dct.c -O0 (test for excess errors) This is my bug. I didn't notice that for some reason vmx.exp adds -std=gnu99. I'm looking at it now. Sorry about that. Ian
Address of variables in the bss/text segments of a shared library
When I use &__bss_start, &_end, in a shared library I get the addresses of the __bss_start and _end of the main application that has loaded the library. I would like to get the address of the bss/text segments of the shared library itself. Thanks Scott Brooks
Re: Address of variables in the bss/text segments of a shared library
On Wednesday 14 March 2007 00:36, Scott Brooks wrote: > When I use &__bss_start, &_end, in a shared library I get the addresses of > the __bss_start and _end of the main application that has loaded the > library. > > I would like to get the address of the bss/text segments of the shared > library itself. This is the wrong place to ask this question. This list is for the development of gcc. You probably want dl_iterate_phdr. Paul
GCC 4.2 branch comparision failure building Java
The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: Comparing stages 2 and 3 Bootstrap comparison failure! ./java/parse.o differs ./java/parse-scan.o differs Has anyone else seen this? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
libgomp failures on powerpc-apple-darwin8
I am noticing one other issue with current gcc 4.2 branch on powerpc-apple-darwin8. We seem to have failures for the following libgomp testsuite tests... FAIL: libgomp.c++/pr30703.C -O0 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O0 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O1 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O1 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O2 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O2 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -g (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -g compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -Os (test for excess errors) WARNING: libgomp.c++/pr30703.C -Os compilation failed to produce executable which appear to be of the form... Executing on host: /sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/ /sw/src/fink .build/gcc42-4.1.-20070312/gcc-4.2-20070312/libgomp/testsuite/libgomp.c++/pr30703.C -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple -darwin8/./libgomp/ -I/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp -I/sw/src/fink.build/gcc42-4.1.-20070312/gcc-4 .2-20070312/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -L/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp/ .libs -lgomp -L/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -m32 -o ./pr3070 3.exe(timeout = 300) /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status FAIL: libgomp.c++/pr30703.C -O0 (test for excess errors) Excess errors: /usr/bin/ld: Undefined symbols: __Unwind_Resume WARNING: libgomp.c++/pr30703.C -O0 compilation failed to produce executable Is anyone else seeing this problem? Jack ps I see this symbol in libgcc_s.1.dylib, libgcc_s.10.4.dylib and libgcc_s.10.5.dylib... nm libgcc_s.1.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume bc68 s __Unwind_Resume.eh 8b10 T __Unwind_Resume_or_Rethrow bbc4 s __Unwind_Resume_or_Rethrow.eh nm libgcc_s.10.4.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume 8b10 T __Unwind_Resume_or_Rethrow nm libgcc_s.10.5.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume 8b10 T __Unwind_Resume_or_Rethrow and undefined in libstdc++.dylib... nm libstdc++.dylib | grep __Unwind_Resume U __Unwind_Resume U __Unwind_Resume_or_Rethrow So I'm a tad confused why the linker isn't resolving it.
Re: Error in checking compat.exp
On Tue, Mar 13, 2007 at 02:07:02PM -0800, Janis Johnson wrote:
> On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
> > Revital1 Eres wrote:
> > >ERROR: tcl error sourcing
> > >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
> > >ERROR: couldn't open
> > >"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C":
> >
> > Note that mainline got changed to xline. Also note that the directory
> > has files bitfield_main.C, bitfield_x.C, and bitfield_y.C.
> >
> > So it looks like there is a tcl script somewhere to replace "main" with
> > "x", which fails if the directory path contains "main" anywhere in it
> > other than in the filename at the end.
>
> That is indeed the problem; testsuite/lib/compat.exp contains
>
> # Set up the names of the other source files.
> regsub "_main.*" $src1 "" base
> regsub ".*/" $base "" base
> regsub "_main" $src1 "_x" src2
> regsub "_main" $src1 "_y" src3
>
> I'll find a way to fix that.
Revital, please try this. I've tested it but know better than to check
things in at the end of the day; I'll post it tomorrow.
Index: gcc/testsuite/lib/compat.exp
===
--- gcc/testsuite/lib/compat.exp(revision 122875)
+++ gcc/testsuite/lib/compat.exp(working copy)
@@ -259,10 +259,13 @@
}
# Set up the names of the other source files.
-regsub "_main.*" $src1 "" base
-regsub ".*/" $base "" base
-regsub "_main" $src1 "_x" src2
-regsub "_main" $src1 "_y" src3
+set dir [file dirname $src1]
+set ext [file extension $src1]
+set base [file rootname $src1]
+set base [string range $base [string length $dir] end]
+regsub "_main" $base "" base
+set src2 "${dir}/${base}_x${ext}"
+set src3 "${dir}/${base}_y${ext}"
# Use the dg-options mechanism to specify extra flags for this test.
# The extra flags in each file are used to compile that file, and the
bootstrap broke in 4.2
../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ: ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true make[3]: *** [var-tracking.o] Error 1 :-( Luckly, we had a chance to break it right before release... :-) Anyway else seeing these?
Query regarding struct variables in GIMPLE
Hi ,
I am trying to convert GIMPLE representation of a program to XML.
GIMPLE does not seem to lower instances of struct variables
E.g.
struct T{int i, int j}x;
f(){ x.j = 10}
appears as x.j = 10 inside the GIMPLE dump of the function body . Is
there some place from where I can get it in the following( or any
other simpler ) form
f()
{
t1 = &x;
t2 = t1+4;
*t2 = 10;
}
I am sorry if this is an already answered question . A search on the
mailing list archives did not give me an answer.
Any help would be greatly appreciated.
--
Karthik
To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson
--
Karthik
To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson
--
Karthik
To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson
Re: bootstrap broke in 4.2
On Mar 13, 2007, at 6:02 PM, Mike Stump wrote: ../../gcc/gcc/var-tracking.c: In function ‘variable_tracking_main’: ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true make[3]: *** [var-tracking.o] Error 1 --- c-opts.c.~1~2007-03-12 15:58:36.0 -0700 +++ c-opts.c2007-03-13 18:18:30.0 -0700 @@ -434,7 +434,9 @@ c_common_handle_option (size_t scode, co warn_sign_compare = value; warn_switch = value; warn_strict_aliasing = value; - warn_strict_overflow = value; + /* APPLE LOCAL breaks the build */ + /* MERGE FIXME */ + /* warn_strict_overflow = value; */ warn_address = value; /* Only warn about unknown pragmas that are not in system lets it build.
Re: bootstrap broke in 4.2
[EMAIL PROTECTED] (Mike Stump) writes: > ../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ: > ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not > occur when assuming that (X - c) >= X is always true > ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not > occur when assuming that (X - c) >= X is always true > make[3]: *** [var-tracking.o] Error 1 > > :-( Luckly, we had a chance to break it right before release... :-) > > Anyway else seeing these? No, I'm not. How are you doing the configure and build? Ian
RE: libgomp failures on powerpc-apple-darwin8
Interestingly, while... gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp -lstdc++ -lm -m32 -o ./pr30703.exe /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status fails on powerpc-apple-darwin8 gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp -lstdc++ -lm -m32 -shared-libgcc -o ./pr30703.exe ...links fine. On powerpc-apple-darwin8, libgcc.a is missing __Unwind_Resume. I wonder why this doesn't show up on any other architectures? Jack
Re: Query regarding struct variables in GIMPLE
Karthikeyan M wrote on 03/13/07 21:32: > appears as x.j = 10 inside the GIMPLE dump of the function body . Is > there some place from where I can get it in the following( or any > other simpler ) form No, we don't unnecessarily take addresses of variables. Structure references are left intact. For some aggregates that cannot be scalarized we try to create artificial tags to represent the fields (to get field sensitive results in points-to resolution).
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Tue, 13 Mar 2007, Andrew Pinski wrote: > On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote: > > Hi Janis, > > > > While PR 28834 stays open, I'm thinking about XFAILing > > gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g. > > However, I am not having any luck with writing mayalias-2.x. I am > > wondering if you could help me with XFAIL. > > There is no way to xfail testcases which fail because of ICEs. This > was decided to go this way so people won't start xfailing them. It's true that in development we may not want to XFAIL them - but it's also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be released with it. And users installing GCC on common platforms should be able to use the testsuite to tell whether their build is working OK, which means that releases should have a baseline of 0 unexpected failures on common platforms. -- Joseph S. Myers [EMAIL PROTECTED]
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On 3/13/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote: On Tue, 13 Mar 2007, Andrew Pinski wrote: It's true that in development we may not want to XFAIL them - but it's also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be released with it. And users installing GCC on common platforms should be able to use the testsuite to tell whether their build is working OK, which means that releases should have a baseline of 0 unexpected failures on common platforms. Except this is a regression which is different from a normal bug that has never worked. Anyways the best way to fix this is just to fix the bug. Someone exposed the regression back in 4.0 time frame, I reported the bug before getting approval for the patch. They were not willing to fix it so why punish the testcase which is obviously is a regression. I think we should be punishing the person who exposed/introduced the regression instead. -- Pinski
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Tue, 13 Mar 2007, Andrew Pinski wrote: > Anyways the best way to fix this is just to fix the bug. Someone We should have 0 unexpected FAILs in 4.2.0 on common platforms (in particular the primary release criteria ones for the testsuites of the languages in the release criteria). How this is achieved is secondary, but if the bug isn't fixed for 4.2.0 the test should be XFAILed - and we know from experience that many regressions aren't fixed for releases, especially where they were present in many previous releases. > exposed the regression back in 4.0 time frame, I reported the bug > before getting approval for the patch. They were not willing to fix > it so why punish the testcase which is obviously is a regression. It's not punishing the testcase; it's recognising that we have a bug tracking system to track regressions and having "expected unexpected FAILs" is helpful neither to users wishing to know if their compiler built as expected nor to developers glancing over test results to see if they seem OK. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Updating libtool in GCC and srctree
On Mar 9, 2007, Steve Ellcey <[EMAIL PROTECTED]> wrote: > If I just run autoconf I get errors because I am not > including the new ltoptions.m4, ltsugar.m4, and ltversion.m4 files. I'd just prepend them to our local copy of libtool.m4, pretty much like aclocal would have done into aclocal.m4. > But boehm-gc has no acinclude.m4 file That's equivalent to an empty one. I'd guess an existing acinclude.m4 was removed in a merge or something like that, because its aclocal.m4 couldn't possibly contain the sinclude statements it does otherwise. Unless someone added them to an aclocal-generated file, which doesn't seem to match this file's history. How about copying the m4_include statements to acinclude.m4, (incorrectly) removed a while ago, and then re-create aclocal.m4 with aclocal? > and while libffi has an acinclude.m4 file, it doesn't have an > include of libtool.m4. This is a bug similar to that of boehm-gc above. > So my question is, how is the include of libtool.m4 getting into > aclocal.m4? Magic ;-) Someone probably failed to realize that they should be in acinclude.m4 in order for them to survive an aclocal run. > This is aclocal 1.9.6. Any idea on what I need to do here to fix this > error? Why do some acinclude.m4 files have explicit includes for > libtool files (libgfortran, libgomp, etc) but other's don't (libffi, > gcc). libffi/ is a bug (it's in aclocal.m4, but not in acinclude.m4). gcc/ doesn't use libtool at all. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: PATCH: make_relative_prefix oddity
On Mar 13, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > It treats only "/opt" as a common component of the two paths, rathe > than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for > the last argument, the answer is as I expected. This seems odd to me; > is it the intended behavior? IIRC this is intended behavior, to enable stuff such as "/some/dir-suffix" and "/another/different-suffix" to generate the correct relative pathnames, when given "/some/dir" as prefix. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Constrain not satisfied - floating point insns.
Hi all,
I am currently adding floating point support for a private target (for
GCC 4.1.1). i am having some problems with register allocation.
In SF mode, i have specified to the compiler that it can use both
floating point registers as well as data registers. For all move
instructions in SF mode, i can use both these registers. But while
moving data from/to memory, i can use only floating point registers.
(define_expand "movsf"
[(set (match_operand:SF 0 "general_operand" "")
(match_operand:SF 1 "general_operand" ""))]
""
"
{
if (GET_CODE (operands[0]) == MEM) {
operands[1] = force_reg (SFmode, operands[1]);
})
(define_insn "movsf_store"
[(set (match_operand:SF 0 "memory_operand" "=m")
(match_operand:SF 1 "float_reg""f"))]
""
"stf \\t%1, %0"
)
But if the compiler tries to move a data register to memory, i get
constraint not satisfied error (ICE).
1. Is there any way to prevent the compiler from using data registers.
2. As a work around, i did the following:
a) In define expand, i check whether the register is a data register.
b) If it is a data register, generate a callee saved register
(floating point register).
c) Emit a move insn from data register to floating pt register.
d) Change the second operand to floating point register so that my
define_insn pattern is matched properly.
Is it advisable to follow this method or is there a better way to
handle this problem?
Regards,
Rohit
