On 10 sep 2005, at 02:03, Richard Henderson wrote:
On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote:
2) Next, I defined parallels to keep things together. Like the
following, with another for DImode.
This seems most reasonable to me.
Especially as the ABI states that the write o
I realise that according to the C++ standard it isn't legal to compare
two pointers which are not from the same array. Is anyone aware of
anything in g++ which would actually forbid this, and if there is any
way of checking if will be valid?
I want to be able to perform two main operations. Firstl
chris jefferson wrote:
>I realise that according to the C++ standard it isn't legal to compare
>two pointers which are not from the same array. Is anyone aware of
>anything in g++ which would actually forbid this, and if there is any
>way of checking if will be valid?
>
In my opinion we should fir
Paolo Carlini wrote:
>Then, as far as *our* library (and compiler) are concerned, there is the
>interesting example of basic_string::_M_disjunct: with Nathan's
>substantive insight we came to the conclusion that such kind of
>comparisons can be always meaningful to do (at the C++ library level) if
On Tue, Sep 13, 2005 at 11:28:07AM +0200, Segher Boessenkool wrote:
> Especially as the ABI states that the write of the backlink
> and the stack pointer update _have_ to be done in one insn.
That's on allocation. Deallocation isn't so critical. You just need to
ensure the backchain is written b
Especially as the ABI states that the write of the backlink
and the stack pointer update _have_ to be done in one insn.
That's on allocation. Deallocation isn't so critical. You just need
to
ensure the backchain is written before updating sp.
Yes, but your example generated code showed all
Hello,
I have the following insn:
(insn 522 521 523 87 (set (reg:SI 308)
(reg:SI 0 ax)) 40 {*movsi_1} (nil)
(insn_list:REG_RETVAL 520 (expr_list:REG_EQUAL (parity:DI (reg:DI 248 [
D.1874 ]))
(nil
Is this correct? I have a piece of code that breaks if mode of the
assi
I am now going to start spinning 4.0.2 RC1.
(I was planning to do that last weekend, but it didn't happen.)
Therefore, as of now, the GCC 4.0 branch is frozen. If you've had a
patch approved for 4.0.2 that's not yet been checked in, and you want to
check it in, please send me the patch URL; I'll
On Fri, 9 Sep 2005, Jonathan wrote:
> i could become a mirror if you want
>
> i'm from rome italy
> the server is in Arezzo Italy
>
> i have 3 domains that you could mirror though if u wanted
> let me know please :)
>
> win.ac3bf1.com
> lnx.ac3bf1.com
> rjn.it
>
> P.S. = send me the files t
> Is there any plan to support Windows/x86-64?
I haven't heard of anyone wanting to work on such a port.
> What are needed for the port?
What you'ld need for any OS port. GCC needs to support the Windows
x64 ABI, you need a suitable runtime library, and you need a suitable
assembler and linker.
On Mon, 12 Sep 2005, Mark Mitchell wrote:
> In summary, I think that splitting GCC optimization efforts between FSF
> and ORC back-ends is unfortunate. I would far rather that the free
> software community be united behind a single optimizer. But,
> fundamentally, I don't see much that we can do
Gerald Pfeifer wrote:
> Do I understand correctly that the new backend is not planned to be
> included in FSF GCC?
That seems unlikely, in the medium-term, at least. Some people have
rasied legal issues, which I know nothing about, but the code has not
been assigned to the FSF. But, those are
I have seen both in gcc. I have found that "type* variable" is
preferred in C++ code but I haven't found any guidelines for C code.
Thanks,
Rafael
On Sep 13, 2005, at 12:23 PM, Rafael Espíndola wrote:
I have seen both in gcc. I have found that "type* variable" is
preferred in C++ code but I haven't found any guidelines for C code.
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
On 9/13/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> If you ask gcc, you find:
>
> mrs $ grep 'int\* ' *.c | wc -l
> 4
> mrs $ grep 'int \*' *.c | wc -l
> 369
>
> pretty clear to me.
In treelang/parse.y all variables named "tok" (and some others) are
declared with
struct prod_token_p
thanks, that works but it seems to require a -g. is there any flag
which might also generate just this line information but avoid most of
the other debug information.
shrey
On 9/11/05, Dale Johannesen <[EMAIL PROTECTED]> wrote:
>
> On Sep 11, 2005, at 8:09 AM, shreyas krishnan wrote:
>
> > Hi,
On Tue, 13 Sep 2005, Rafael Espíndola wrote:
On 9/13/05, Mike Stump <[EMAIL PROTECTED]> wrote:
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
pretty clear to me.
In treelang/parse.y all variables named "tok" (and some others) a
Joe Buck wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appears that 'clone' is not suppo
The interesting thing to note is that if I edit this and only do one
clone call, things work. As soon as I attempt to do a second clone,
things fall apart when debugging symbols with '-O0 -g' are compiled.
Again, the source link is below. I am going to have to make a note
of this bug and come back
On Tue, 13 Sep 2005, Steven J. Hill wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appear
On Tuesday 13 September 2005 18:11, Daniel Berlin wrote:
> So, uh, change them :)
I have just submitted a patch :)
Rafael
pgpOrEeEKuddE.pgp
Description: PGP signature
Any reason why we blindly assume destination registers will be hard
registers here?
Index: regmove.c
===
RCS file: /cvs/gcc/gcc/gcc/regmove.c,v
retrieving revision 1.173
diff -p -U3 -r1.173 regmove.c
--- regmove.c 25 Aug 2005 06:44
Snapshot gcc-3.4-20050913 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050913/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050913
You'll
For a while gccadmin's crontab has been out of sync with the version in
CVS (maintainer-scripts/crontab). That in use has
43 10 * * 5 sh /home/gccadmin/scripts/gcc_release -s 4.1:HEAD -l -d
/sourceware/snapshot-tmp/gcc all
while that in CVS has
43 17 * * 6 sh /home/gccadmin/scripts/
On Tue, Sep 13, 2005 at 11:22:18AM +0100, chris jefferson wrote:
> I realise that according to the C++ standard it isn't legal to compare
> two pointers which are not from the same array. Is anyone aware of
> anything in g++ which would actually forbid this, and if there is any
> way of checking if
DJ Delorie <[EMAIL PROTECTED]> writes:
> Any reason why we blindly assume destination registers will be hard
> registers here?
>
> Index: regmove.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/regmove.c,v
> retrieving revision 1.173
> diff -p
Hi,
I have a function written in fortran say fun(x, y), with x and y as integer
(scalars) . Function returns integer.
I need to call this function from a C program. How do I do it.
Can some one help me.
Does Gfortran and gcc support this. ??
Regards
Gaurav
27 matches
Mail list logo
