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
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.
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
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
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
"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 i
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-behaviou
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.
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 (
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 implement
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 questio
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, i
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++) ar
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
14 matches
Mail list logo
