Re: g++.dg not having one .exp per directory
make RUNTESTFLAGS="dg.exp=nothrow-1.C" check-g++ This one I know of. dg.exp=eh\*.C is another one. I was missing the *back* slash. I guess it is actually make RUNTESTFLAGS='dg.exp=eh\\*.C' to get the correct escaping when RUNTESTFLAGS is expanded? Thanks, Paolo
Re: fwprop patch testing
The only big regression for fwprop on PPC is bzip2. I've distilled it
to this small testcase:
int f(int *);
int verbosity;
int *arr;
int last;
void g ()
{
int i;
if (last < 4000) {
if (verbosity >= 4) f(&verbosity);
for (i = 0; i <= last; i++) arr[i] = i;
}
}
where CSE previously was performing load PRE. So, actually this
regression is caused by -fno-cse-skip-blocks rather than deleting parts
of fwprop. Note that this can be performed on the GIMPLE-level only to
some extent. What we are looking for is the following pseudo-C:
void g ()
{
int i;
int *plast = &last;
int mylast = *plast;
if (mylast < 4000) {
if (verbosity >= 4) f(&verbosity);
i = 0;
mylast = *plast;
while (i <= mylast)
{
arr[i] = i;
/* Note the unfortunate aliasing between arr and plast */
mylast = *plast;
}
}
}
And tree-based load PRE can only get to
void g ()
{
int i;
int *plast = &last;
int mylast = *plast;
if (mylast < 4000) {
if (verbosity >= 4) f(&verbosity);
i = 0;
plast = &last; /* redundant */
mylast = *plast;
while (i <= mylast)
{
arr[i] = i;
plast = &last;/* redundant, and very expensive! */
mylast = *plast;
}
}
}
since the "plast" lowering is obviously happening during expand.
I have not yet looked at whether it is possible to teach fwprop about
this case, but I am not sure it is possible (I'm more inclined to think
that it is simply not fwprop's job). Right now, I am thinking more
about shuffling the pass order. One possibility that comes to mind is
GCSE+fwprop+CSE, where GCSE could work out the common code for loading
the address, and fwprop/CSE could do the addressing mode selection properly.
On one hand, this may mean increasing the number of GCSE passes from 1
to 2. On the other hand, it may mean that the CSE pass at the hand of
rest_of_handle_gcse could become redundant.
Paolo
Re: PATCH RFC: Increase support for restrict qualifier
On 25 Sep 2005 10:10:39 -0700, Ian Lance Taylor wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > second, how often does this actually set anything useful with restrict > > types (I assume the value is not interesting in any other cases)? > > In functions which use the restrict qualifier, it does something > useful pretty often: just about every time the restricted pointer is > used other than as a simple *p. The real question, which I don't know > the answer to, is how much that helps in common code. (It does make a > significant difference in certain key functions at my current job.) It does gain about 2-5% for certain C-to-POOMA comparison benchmarsk (only for the C part of course). Also we have PRs about this and it is a regression. So I defenitively would welcome a patch to do this for 4.1 (and even 4.0). Richard.
Gomp and C++?
Hi, during the last weeks there has been a great deal of activity on the gomp-branch, which I find very exciting, since I work on some OpenMP-enabled codes and would like to become more independent of the Intel compilers. Unfortunately these codes are all written in C++ :( So here is my question: are there any plans for OpenMP support in C++ in the near future, or will the C and Fortran parts be finished first? Thanks in advance, Martin
Re: Gomp and C++?
On September 26, 2005 09:35, Martin Reinecke wrote: > So here is my question: are there any plans for OpenMP support in C++ > in the near future, or will the C and Fortran parts be finished > first? > Yes, we will also implement C++. It's planned after we have a sufficiently complete C implementation. In theory, there should be quite a bit of overlap but C++ does have a few wrinkles here and there.
Re: [RFC] patch to fix an ICE involving sign-extract of mmx expression
On Sep 23, 2005, at 12:41 PM, Richard Henderson wrote: On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote: /* Avoid creating invalid subregs, for example when simplifying (x>>32)&255. */ ! if (final_word >= GET_MODE_SIZE (inner_mode) ! || (final_word % GET_MODE_SIZE (tmode)) != 0) return NULL_RTX; I think you should just call validate_subreg. Ok with that change. This is the patch I am checking in. - fariborz ([EMAIL PROTECTED]) ChangeLog: 2005-09-26Fariborz Jahanian <[EMAIL PROTECTED]> * combine.c (make_extraction): Check for valid use of subreg. Index: combine.c === RCS file: /cvs/gcc/gcc/gcc/combine.c,v retrieving revision 1.503 diff -c -p -r1.503 combine.c *** combine.c 26 Aug 2005 21:52:23 - 1.503 --- combine.c 26 Sep 2005 16:01:23 - *** make_extraction (enum machine_mode mode, *** 6314,6320 /* Avoid creating invalid subregs, for example when simplifying (x>>32)&255. */ ! if (final_word >= GET_MODE_SIZE (inner_mode)) return NULL_RTX; new = gen_rtx_SUBREG (tmode, inner, final_word); --- 6314,6320 /* Avoid creating invalid subregs, for example when simplifying (x>>32)&255. */ ! if (!validate_subreg (tmode, inner_mode, inner, final_word)) return NULL_RTX; new = gen_rtx_SUBREG (tmode, inner, final_word); r~
Re: g++.dg not having one .exp per directory
On Sep 26, 2005, at 12:08 AM, Paolo Bonzini wrote: I was missing the *back* slash. I guess it is actually make RUNTESTFLAGS='dg.exp=eh\\*.C' $ make RUNTESTFLAGS=dg.exp=eh\*.C check-g++ or $ make RUNTESTFLAGS='dg.exp=eh*.C' check-g++ Once you get past local shell quoting, you're ok. Didn't you ever wonder why we use common prefixes to testsuite names? :-)
The behaviours of the pointers according to the operating system
I wonder the differences between the behaviours of the pointers according to the operating systems while compiling with gcc .And the differences between the gcc and the other compilers.Can you please help me?? -- Sent from the gcc - General forum at Nabble.com: http://www.nabble.com/The-behaviours-of-the-pointers-according-to-the-operating-system-t348038.html#a964501
Re: The behaviours of the pointers according to the operating system
"sek_saf_on \(sent by Nabble.com\)" <[EMAIL PROTECTED]> writes: > I wonder the differences between the behaviours of the pointers > according to the operating systems while compiling with gcc .And the > differences between the gcc and the other compilers.Can you please > help me?? This question is probably best directed to [EMAIL PROTECTED] Thanks. In general there are no differences in pointer behaviour for the operating systems which are targeted by gcc, and in general gcc handles pointers the same as other compilers do. In particular, gcc does not target the 80286 (though I believe there are patches out there). Can you be more specific in your question? And, if appropriate, send it to gcc-help? Thanks. Ian
Re: reload-branch created (was: What to do with new-ra for GCC 4.0)
On Fri, Mar 18, 2005 at 07:15:11PM +0100, Bernd Schmidt wrote: > Jeffrey A Law wrote: > >On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote: > > > >>Why not putting it on a branch? If you are going to finish and submit it > >>for > >>4.1, it might be easier to use CVS. > > > >It might also be easier for those of us who want to play with the code, > >without having to find a suitable sync point between the patch and > >mainline sources. > > I have created a new branch, "reload-branch", on which I'm going to > check in these changes. Once I've done that, I'll commit the patch > below to mention the branch in the documentation. Hey Bernd, Has there been any news or progress on reload-branch lately? It removes a lot of code that I'd dearly love to see gone... -- Daniel Jacobowitz CodeSourcery, LLC
DERIVED_FROM_P
Hi: I'm using the The intermediate representation used by the C and C++ front ends: http://gcc.gnu.org/onlinedocs/gccint/Trees.html I need know what DERIVED_FROM_P do and How use this... Is there any source code sample? Thanks! -- Humberto
Re: DERIVED_FROM_P
On Sep 26, 2005, at 5:25 PM, Humberto Rocha wrote: I need know what DERIVED_FROM_P do and How use this... What part of the comment: /* Nonzero iff TYPE is derived from PARENT. Ignores accessibility and ambiguity issues. */ #define DERIVED_FROM_P(PARENT, TYPE) \ was unclear? If you didn't read that comment, you'll want to examine the various files in doc/*.texi for documentation, as well as the definitions themselves. Is there any source code sample? Yes, please see the gcc source code.
fixed registers in mips
Hello,
I'd like to ask a question about target macros of registers. In
mips.h, the fixed registers are defined as follows:
/* By default, fix the kernel registers ($26 and $27), the global
pointer ($28) and the stack pointer ($29). This can change
depending on the command-line options.
Regarding coprocessor registers: without evidence to the contrary,
it's best to assume that each coprocessor register has a unique
use. This can be overridden, in, e.g., override_options() or
CONDITIONAL_REGISTER_USAGE should the assumption be inappropriate
for a particular target. */
#define FIXED_REGISTERS \
{ \
1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, \
/* COP0 registers */ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
/* COP2 registers */ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
/* COP3 registers */ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1\
}
I'd like to know why mips doesn't define $30 and $31 as fix registers?
And when should they be defined true?
Thanks very much.
Eric.
Re: fixed registers in mips
Eric Fisher <[EMAIL PROTECTED]> writes: > I'd like to know why mips doesn't define $30 and $31 as fix registers? > And when should they be defined true? Neither register has a use which is fixed by either the hardware or the ABI. $30 is generally the frame pointer, but gcc will only use a frame pointer which it is required to. When a function does not need a frame pointer, $30 is available as a caller-saved register. $31 is used by hardware in a jal instruction, and the ABI requires its used in a jalr instruction. However, in code that does not make a function call, it is perfectly reasonable for gcc to use $31 as a general caller-saved register, assuming of course that gcc has saved the address to which the function should return. Ian
