On Tue, 1 Mar 2005, Alec Voropay wrote:
> It seems, the local on the GCC web page
> http://gcc.gnu.org/install/specific.html
> does not work due to wrong HTML format.
I'm afraid that, originally, I didn't understand what you meant by this,
but I believe that I do now and thus I committed a fix f
Hello Gaby,
do you still confirm the release date which was last reported here:
http://gcc.gnu.org/ml/gcc/2005-01/msg01253.html
that is, will GCC 3.3.6 released on April, 30th? And will it be the last
release of the GCC 3.3 series?
Thanks,
Giovanni Bajo
On Tue, 12 Apr 2005, Dave Korn wrote:
>> When I look in gcc-4.0.0-20050410/INSTALL at specific.html
> Oh, BTW, it seems the internal links in that page are b0rked in the usual
> sort of way, owing to the mangling of 'special' characters. A link like:
>
> *-ibm-aix*
>
> doesn't actually link up
On Wednesday 20 April 2005 06:12 am, Gerald Pfeifer wrote:
> On Tue, 1 Mar 2005, Alec Voropay wrote:
> > It seems, the local on the GCC web page
> > http://gcc.gnu.org/install/specific.html
> > does not work due to wrong HTML format.
>
> I'm afraid that, originally, I didn't understand what you m
In the GCC documentation (gcc/doc/install.texi) we have the following
texinfo snippet
@emph{You should substitute @samp{i686} in the above command with the
appropriate processor for your host.}
makeinfo 4.8 translates this to
You should substitute `i686
' in the above command with the a
On Wed, 20 Apr 2005, Patrick McFarland wrote:
>>> http://gcc.gnu.org/install/specific.html
> I think he meant it has the wrong doctype. That is clearly an xhtml
> document, but it has an html4 doctype.
If you pass this page through validator.w3.org, you'll see that this
is clearly *not* an XHTML
Hi Gerald,
You should substitute `i686
' in the above command with the appropriate processor
for your host.
Thanks for the report, I'll work on fixing that.
karl
On Wed, 20 Apr 2005, Giovanni Bajo wrote:
| Hello Gaby,
|
| do you still confirm the release date which was last reported here:
| http://gcc.gnu.org/ml/gcc/2005-01/msg01253.html
|
| that is, will GCC 3.3.6 released on April, 30th? And will it be the last
| release of the GCC 3.3 series?
All those
As I have written in an earlier post here, I'm trying to vectorize some
loops with intrinsics and I have also got a gcc 4.1 snapshot (20050410).
However when I try to compile my code with the gcc-4.1 snapshot I get:
/msys/1.0/home/mingw/bin/gcc.exe -g -Wall -O3 -msse -mtune=pentium3
-DHAVE_CONF
> Think about it for a while -- given a SET where the SET_SRC is a
> pseudo which did not get a hard register and is equivalenced to
> a read-only memory location, then the SET must be dead as it
> can only be setting the memory location to the value already
> in the memory location.
Was that long
On Wed, Apr 20, 2005 at 12:12:21PM +0200, Gerald Pfeifer wrote:
>
> I'm afraid that, originally, I didn't understand what you meant by this,
> but I believe that I do now and thus I committed a fix for this problem
> two days ago.
Thank you. As I see, you've changed all *-* in anchors with
x-x .
On Wed, 2005-04-20 at 17:18 +0200, Eric Botcazou wrote:
> > Think about it for a while -- given a SET where the SET_SRC is a
> > pseudo which did not get a hard register and is equivalenced to
> > a read-only memory location, then the SET must be dead as it
> > can only be setting the memory locati
Ãystein Johansen <[EMAIL PROTECTED]> writes:
> As I have written in an earlier post here, I'm trying to vectorize
> some loops with intrinsics and I have also got a gcc 4.1 snapshot
> (20050410). However when I try to compile my code with the gcc-4.1
> snapshot I get:
>
> /msys/1.0/home/mingw/bin
> Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo
> which did not get a hard register and is equivalent to a readonly
> memory location that the insn is useless?
Yes, I think so: being equivalenced implies that there was a REG_EQUIV note,
so the insn cannot do anything else than
On Wed, 2005-04-20 at 18:51 +0200, Eric Botcazou wrote:
> > Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo
> > which did not get a hard register and is equivalent to a readonly
> > memory location that the insn is useless?
>
> Yes, I think so: being equivalenced implies that ther
> Jeffrey A Law wrote:
> ...
> But what worries me even more is spilling. Say a pseudo has a hard reg
> assigned and is also equivalent to a readonly memory location. Reload
> then decides to spill the pseudo out of the hard reg because the hard
> reg was needed for something else. When that occ
Looks like it disappeared here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00613.html
I think the list of i386 builtin functions is now out of date in the
documentation.
The following differences now exist between the documentation and the
current 4.1 x86 code.
I do not know whether all of
>
> > Looks like it disappeared here:
> > http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00613.html
> >
> > I think the list of i386 builtin functions is now out of date in the
> > documentation.
>
> The following differences now exist between the documentation and the
> current 4.1 x86 code.
Sorry, to be clearer, what I meant by:
> From: Paul Schlie <[EMAIL PROTECTED]>
> .. (thereby the pseudo is now equated with the spilled value), or ...
was: (thereby the pseudo is now equated with an allocated temporary
memory location, now storing the spilled value), or ...
Andrew Pinski wrote:
Yes this was intentional, you should not be using the builtin functions,
instead use intrinsics from the header files.
I've just rewritten the code to use the intrinsics from the header files
(xmmintrin.h). It now reads _mm_foo() instead of __builtin_ia32_foo().
The problem n
On 14 Apr 2005, John David Anglin spake:
>> : build/genattrtab
>> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/
>> rs6000.md > tmp-attrtab.c
>> :
>> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
>
> You need to increase the application limits
On Wed, Apr 20, 2005 at 08:16:22PM +0100, Nix wrote:
> On 14 Apr 2005, John David Anglin spake:
> >> : build/genattrtab
> >> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/
> >> rs6000.md > tmp-attrtab.c
> >> :
> >> : out of memory allocating 12016 bytes after a total of
On 4/20/05, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Yes this was intentional, you should not be using the builtin functions,
> instead use intrinsics from the header files.
Now that intrinsics are first class citizens it would be a real plus
if someone could convince gcc to not spit horrors like
In page:
http://gcc.gnu.org/onlinedocs/gcj/Objects-and-Classes.html
- Specifically, 8-bite and 16-bit native types
+ Specifically, 8-bit and 16-bit native types
On the same page there is a Java example that will not compile, I found and
fixed 3 bugs; Please replace with:
public class Int
Snapshot gcc-3.3-20050420 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050420/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050420
You'll
My port failed the DImode part of the rotate regression-tests
(gcc.c-torture/execute/20020508-[123].c). I found that
emit_no_conflict_block() reordered insns gen'd by
expand_doubleword_shift() in a way that violated dependency between
compares and associated conditional-move insns that had the tar
Martin Koegler wrote:
> Placing variables in a specfic section is only a part of the problem.
I am aware of that. There are already many targets that have special
handling for section attributes, that result in different code being
generated when a section attribute is present. Mostly these hav
Daniel Towner wrote:
This no longer appears to be the case? `assemble_name' is still called
with `fn', and correctly marks `fn' as being referenced, but no body is
ever emitted.
-fno-unit-at-a-time might help. This disables some of the cgraph
optimizations. This will probably go away eventuall
Hi,
A code segment from Itanium platform.
Note the instruction at 0x4722, what does this mean?
I'vd gdbed the program, r2=0, so 0x4722 just not executes.
This puzzles me because I am working on analyzing elfs depends on br
Instructions. Can I call into the internal of a fun
> - i386.h provides undocumented -mwindows and -mdll options.
> I've put these in their own file (dummy-windows.opt) so that
> cygwin and mingw can provide properly-documented versions.
which means it is likely that Kenner and/or ACT wrote the patch.
I didn't write it.
Joern RENNECKE wrote:
required for Tal16bool. Should we enforce that any storage element
allocated
for a run of ms-bitfields get the full alignment of the basetype, even
when it exceeds
the size of the basetype and of BIGGEST_ALIGNMENT?
Obviously, we should do the exact same thing that the micro
Björn Haase wrote:
The mid-end seems not to be able to simplify nested subreg expressions. I.e.
it seems that there is no known transformation
(subreg:QI (subreg:HI (reg:SI xx) 0) 0)
Nested subregs aren't valid. You should refrain from creating them.
(define_expand "xorhi3"
[(set (subreg:QI
Denis Vlasenko wrote:
Yes. wp512_process_buffer() was using 3k of stack if compiled with -O2.
The wp512.c I appended (sans table at top) is instrumented to show it.
Use "make crypto/wp512.s".
See
http://gcc.gnu.org/bugs.html
for info on reporting gcc bugs.
We need a testcase that we can use to
On Thu, Apr 21, 2005 at 10:41:40AM +0800, Zhenyu Guo wrote:
> Hi,
> A code segment from Itanium platform.
> Note the instruction at 0x4722, what does this mean?
> I'vd gdbed the program, r2=0, so 0x4722 just not executes.
> This puzzles me because I am working on analyzing
Zhenyu Guo wrote:
0x4720 : [BBB] nop.b 0x0
0x4721 : (p08)
br.cond.dpnt.few 0x4740
0x4722 :
br.call.sptk.many b0=0x4720 ;;
Most likely this means that you are looking at unlinked (i.e.
unrelocated) code. Did you r
Not really.
Here is my options:
gcc --static test.c -o test
Thx!
-邮件原件-
发件人: James E Wilson [mailto:[EMAIL PROTECTED]
发送时间: 2005年4月21日 11:32
收件人: Zhenyu Guo
抄送: gcc@gcc.gnu.org
主题: Re: Call into a function?
Zhenyu Guo wrote:
> 0x4720 : [BBB] nop.b 0x0
> 0x400
The GCC Steering Committee has appointed Mike Stump as maintainer
of the Objective-C and Objective-C++ front ends. Mike will work
with Ziemowit Laski, who remains a maintainer of these front ends
as well. Thanks, Mike, for volunteering for this job.
Also, Mike, please add yourself to the MAINTAI
On Thursday 21 April 2005 06:16, James E Wilson wrote:
> Denis Vlasenko wrote:
> > Yes. wp512_process_buffer() was using 3k of stack if compiled with -O2.
> > The wp512.c I appended (sans table at top) is instrumented to show it.
> > Use "make crypto/wp512.s".
>
> See
> http://gcc.gnu.org/bug
On Wed, 20 Apr 2005, Daniel Jacobowitz stipulated:
> On Wed, Apr 20, 2005 at 08:16:22PM +0100, Nix wrote:
>> On 14 Apr 2005, John David Anglin spake:
>> >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
>> >
>> > You need to increase the application limits for data on you
39 matches
Mail list logo
