Hi,
I am doing some modification to gcc's RTL code. I am trying to split a
pseudo (old) into two pseudos (old and new)
and rewriting some part of the code to replace the "old" pseudo by the
"new" pseudo. I am using the "replace_rtx" function
to perform the replacement. However I get "fatal error
Andrew Haley wrote:
> Mark Mitchell writes:
> >
> > I also agree with Gaby that we should document this as an extension. If
> > we go to the work of putting it back in, we should ensure that it
> > continues to work for the foreseeable future. Part of that is writing
> > down what we've dec
The following example C code and disassembly is compiled by gcc 3.4.3,
for i686. It uses two different invariants for what the value of
a static link is. Everywhere inside P, static link values are consistently
the same as base pointer (%ebp) register values for the same activation
record. A s
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| int main()
| {
| int i = NULL; // { dg-warning "" } converting NULL to non-pointer type
In many C implementations, NULL is defined as
#define NULL ((void *) 0)
which renders the above initialization ill-formed -- not just a warnin
On Thu, 2006-07-06 at 15:08 -0700, Ian Lance Taylor wrote:
> "Matt Lee" <[EMAIL PROTECTED]> writes:
>
> > Is it possible for me to write a backend that accepts certain
> > addressing modes for loads, while rejecting them for stores? I am not
> > sure how to do this with the GO_IF_LEGITIMATE_ADDRES
Snapshot gcc-4.0-20060706 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060706/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"Matt Lee" <[EMAIL PROTECTED]> writes:
> Is it possible for me to write a backend that accepts certain
> addressing modes for loads, while rejecting them for stores? I am not
> sure how to do this with the GO_IF_LEGITIMATE_ADDRESS macro. I know
> that this is not very sane, but the situation has a
Dear all,
Once the implementation of warnings for coercions that may change a
value in the simplest cases is roughly completed [1], I am starting to
consider other possible cases. As an example, the C++ front end given
the Wconversion option currently emits a warning for:
int i = NULL;
Would it
Hi,
Is it possible for me to write a backend that accepts certain
addressing modes for loads, while rejecting them for stores? I am not
sure how to do this with the GO_IF_LEGITIMATE_ADDRESS macro. I know
that this is not very sane, but the situation has arisen neverthless.
I want to allow only in
I'd like to include cases in the gfortran testsuite to check that we
correctly issue a run-time error, and exit with non-zero code.
I have the following example:
$ cat runtime_error.f90
! { dg-do run }
! { dg-options "-fbounds-check" }
integer :: x(5), y(5)
x = y((/0,2,3,4,6/))
end
$ gfor
Daniel Franke wrote:
HI all.
Could someone please send me the "copyright assignment form"?
Please see the form in
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
One of these days I will have to put this into the wiki.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
J.J.Garcia wrote:
I'm messed with this, anyway i don't understand why the 2.95.3 doesn't have a
testsuite folder within.
Because gcc had no official testsuite at that time, so obviously, there
was no testsuite folder (directory).
We did have a package called c-torture that was released separ
Joern Rennecke wrote:
Andrew Haley wrote:
> > So it seems I have to abandom the system compiler for doing
bootstraps.
Can you make a simple testcase for this?
Andrew.
Attached.
This fails at -O0..-O2 for gcc 3.2.2 and gcc 3.2.3 on
i686-pc-linux-gnu. For gcc 3.4.3,
it still fails at
That may be the difference between "void f()" (where TYPE_ARG_TYPES
might be NULL) and "void f(...)" (where TREE_VALUE (TYPE_ARG_TYPES)
would be NULL). The latter, as Daniel says, is not valid C, but perhaps
we used to accept it.
"void f(...)" is how you refer to an old-style function definit
Mark Mitchell writes:
>
> I also agree with Gaby that we should document this as an extension. If
> we go to the work of putting it back in, we should ensure that it
> continues to work for the foreseeable future. Part of that is writing
> down what we've decided.
We can't make function po
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor wrote:
|
| > I realized that I am still not stating my position very clearly. I
| > don't think we should make any extra effort to make this code work:
| > after all, the code is undefined. I just think 1) we should not
| > insert a t
16 matches
Mail list logo
