On Wed, 2006-07-12 at 17:57, Ian Lance Taylor wrote:
> Personally, I think we should support operator[] for vectors.
Indeed, that was one of the most popular choices when I first brought
this topic up. I contributed mips vector support in August 2004, and in
the multiple threads that patch spawne
On Fri, 2006-07-07 at 13:38, Gerald Pfeifer wrote:
> I'm afraid I have to ask you to remove this again. RMS explicitly
> requested we do not provide this on our web pages, or I would have
> added it years ago.
I thought it was the actual legal forms that weren't supposed to be on
the web site, b
On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> I took the liberty to fix the format issue on behalf of Denis. Is this
> OK for mainline?
Yes, this looks good to me.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> It's corrected and tested on ia64 and x86-64. I've attached new version.
> Denis.
This look pretty good. There is still one place where the spacing looks
funny.
> + if (test >= regno && test < endregno)
> + return 1;
Check
On Wed, 2006-02-15 at 05:52, Denis Nagorny wrote:
> Did I understand your idea correctly? Can you comment new patch version.
> It isn't fully tested but am I going in right direction?
Yes, that is what I was suggesting.
In choose_reload_regs, you only need one regno_clobbered_p call, with
sets ==
On Tue, 2005-11-22 at 01:53, Richard Guenther wrote:
> Like f.i. as I proposed in
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html
> maybe you could comment on that approach. Sofar the feedback was negative,
> so I didn't yet work further on it.
I fell behind on gcc-patches reading a whi
On Tue, 2005-11-22 at 05:44, Rainer Emrich wrote:
> I compared this to an earlier build and I'm sure that the wrong library
> search path is used in this case. It should be:
> Any hints?
It is curious that it got the include options right (-D/-I) but not the
library options (-B/-L).
The option mu
On Sun, 2005-11-20 at 12:01, Rafael Ávila de Espíndola wrote:
> What do you thing about adding an assert? Something similar to the attached
> patch.
I think there is no chance of a user seeing this problem. It can only
occur when working on a front end, in which case the problem would be
obvious
On Tue, 2005-11-15 at 12:01, Peter S. Mazinger wrote:
> I wanted to only know if there is a configuration/scenario where this
> really worked.
I haven't been involved with the stack protector development or usage,
but as far as I know, it works unless some one reports a bug, and the
only bug I c
On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote:
> I have really hoped that someone here can duplicate it in any environment
In that case, I'd suggest creating a bugzilla bug report. The gcc list
is really more of a self-help list for gcc developers. If you want to
try to debug the problem
On Tue, 2005-11-15 at 01:11, Jim Blandy wrote:
> 'svn revert' doesn't work for you? What does 'svn status' say?
aretha$ svn revert tree-vrp.c
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
aretha$ svn cleanup
svn: In directory '.'
svn: Ca
On Mon, 2005-11-14 at 18:16, Gabriel Dos Reis wrote:
> I was under the impression that the DECL_RESULT is nullified for a
> function that passes the named return-value optimization.
Just using grep, I don't see any obvious evidence of that. I don't know
where to look for more info. I see a numb
On Tue, 2005-11-08 at 17:22, Albert Chin wrote:
> A .depot file is a tar file so just untar it.
Yeah, I knew that, it just took me a while to remember. I added
comments to PR 24718 explaining what the underlying problem is, and
confirming the bug. I probably can't do much more as I don't have an
On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> Unfortunately I have no way of finding out more about the local "install",
> as it doesn't accept the --help flag:
Did you check to see if it might be a shell script? If so, there might
be comments in it. If it isn't a shell script, then runn
On Tue, 2005-11-01 at 11:39, Steven Bosscher wrote:
> Wasn't this whole issue fixed by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01785.html
Yes. Andreas Schwab's patch appears to fix this correctly.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Tue, 2005-10-25 at 01:08, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame:
That is probably a reasonable solution if it can be implemented
cleanly. There are already some differences. debug_frame info can
On Tue, 2005-10-25 at 11:34, Joern RENNECKE wrote:
> It can't be easily implemented in target-specific code alone. Sometimes
> there is code after the epilogue, so there would have to be
> a mechanism to get the dwarf virtual machine back to the pre-epilogue state.
There is.
I'm more conversant
Andrew B. Lundgren wrote:
> Is there a macro I can ifdef on to check to see if I can use the v8plus
> instructions, otherwise use the existing spinlock implementation?
It looks like we have __sparc_v8__ and __sparc_v9__ but not a macro for
v8plus. If you need one, you may have to add it. See CPP
Mike Ainley wrote:
> This web site is turning away Microsoft Internet Explorer 5.
Are you using a download accelerator? The gcc.gnu.org site refuses most
of them, as they cause load issues on our server. They are also popular
with spammers, who use them for spam bots. The message you are seeing
Fred Fish wrote:
> It appears that the ia64 port introduced the internal define
> MASK_GNU_AS that is used the same was as the historical MASK_GAS
> define. There was some discussion of this about 5 years ago as part
> of a larger discussion about possible user level changes.
Is there a reason wh
Gaurav Gautam, Noida wrote:
> I want to know, how enums are handled in gcc. How do we map an enum value to
> the corresponding integer size.
Look at start_enum and finish_enum in c-decl.c.
> What does the option -fshort-enums does. Plz explain me in detail.
Look at the code in start_num and fin
On Fri, 2005-08-26 at 01:46, Etienne Lorrain wrote:
> Shall I create a new bug report or re-open:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
That's a different bug, in the gimplifier. This one is in the
middle-end in expand_expr. I'd
Etienne Lorrain wrote:
> Investigated again a big increase of size going from GCC-3.4 to 4.x
> (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
> to reproduce:
If you want this fixed, you should file a bug report into our bugzilla
database.
Here is a quicker way to reprod
Dale Johannesen wrote:
> This is wrong, because 4 bytes starting at 73 goes outside the original
> object and can
> cause a page fault.
FYI You can write a testcase for this by using mmap to allocate a page
of memory, putting a copy of the structure 76 bytes from the end of the
mmapped region, and
Ralf Schubert wrote:
> is there any reference about the warning- and error-messages gcc (e.g.
> 4.0.1) produces when compiling a C-source code ?
> What I'm looking for is a summary with some explanations. I tried hard,
> but couldn't find something suitable.
We don't have a list of all of the warn
Nick Clifton wrote:
> The reason for this behaviour is that the debug information is being
> written out before the variables have been fully resolved. In
> particular DECL_SET() for the second and third observer functions is
> NULL when the debug info is generated, which is why they are b
ji an wrote:
> when I input the command line:
>>g++ -m64 -o test test.cc
> error message was output:
> /tmp/ccyjpGIh.o(.text+0x900): In function `main':
> : relocation truncated to fit: R_X86_64_32
This kind of question is more appropriate for gcc-help. The gcc list is
intended for questions abou
[EMAIL PROTECTED] wrote:
> main.c:7: internal compiler error: in purge_addressof, at
> function.c:3423
Oh, I forgot to mention, purge_addressof disappeared over a year ago, so
few people are going to care about this. You are doing a port to
gcc-3.4.x perhaps? It is important to include inf
[EMAIL PROTECTED] wrote:
> It's the mem rtx makes the difference,
> but I don't know where the mem rtx comes from.
> I have no idea about it.
The real question here is why did purge_addressof_1 fail? You didn't
provide that info.
There are so many different things that could be wrong here that I
Torsten Mohr wrote:
> In that file i've also read about an option "ghs", does
> that one switch to the Greenhills ABI?
In theory, yes. In practice, I'd be skeptical. It probably hasn't been
well tested.
> From that file i can't really conclude everything.
> For example i don't know if registers
On Tue, 2005-08-23 at 07:44, Bernd Schmidt wrote:
> Jim Wilson once suggested we should just emit insns to make sure every
> register is initialized and be done with it - problem solved. I had
> started to work on that, if people think it's a good idea I can dig that
> stuff out again.
I'd lik
[EMAIL PROTECTED] wrote:
> 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
> building in "fixincludes" uses the gcc (with no PATH specification)
> instead of the xgcc build by the last stage. It may crash, it happens on
> my environment, because I've migrated from Solaris 9 to S
Piotr Wyderski wrote:
> I have disassembled my program produced by g++ 4.0.0
> and I see a very strange behaviour -- the compiler doesn't
> generate cmov-s (-O3 -march=pentium3). G++ 3.4 generates
> them. So, how can I reactivate cmov-s in the newest version
> of the compiler? fif-conversion doesn'
Ling-hua Tseng wrote:
> It's only correct if the two RISC insns reserved the same RISC function
> unit.
Try defining two separate reservations for each pipe, e.g. a
risc_data_processing_r0 and a risc_data_processing_r1. Then you can
write the bypass rule in the obvious way.
--
Jim Wilson, GNU To
Joe Buck wrote:
> The digits we use come from the Arabs, and look much the same in Arabic.
> Check an Arabic-language site, for example http://www.aljazeera.net/ .
In English, we call them "Arabic Numerals", but that is a bit of a
misnomer. Once upon a time, a long time ago, some Arabs used digit
Erik Christiansen wrote:
> I've taken the liberty of cleaning up the L_callt_save_interrupt
> #ifdef, making it consistent with the following one for
> L_callt_save_all_interrupt. (This not only removes the .text error, but
> adopts the easier to handle layout of the latter.)
Patches should be sen
Torsten Mohr wrote:
> I wonder now how to proceed, do i need to report this stuff officially
> somewhere? I also got no answer to my mail from saturday morning,
> subject line "-mwarn-signed-overflow". I had to do that change to
> make gcc-3.4.4 compile.
gcc bugs can be reported into our bugzill
F. Heitkamp wrote:
> a particular cpu. Looking at the specs file for the host compiler the
> default is -mppc. When I gave the "--with-cpu=7400" shouldn't that have
> made the default -m7400?. What about xgcc, how can I make that use
> the 7400 cpu?
Perhaps this is a case that gcc doesn't hand
Balaji V. Iyer wrote:
> Pass this "live/not-live" flag to the register allocation process so that
> it can output instruction in such a way (please see example below) (I want
> this information to be passed into .md stage)
You can't get cycle-accurate life time info in the register allocator
unles
Daniel Towner wrote:
> register renaming is able to change the registers used by the function
> from callee-save to caller-save, removing any need for the
> save/restore/stack adjust code in the prologue/epilogue. However, the
> instructions which perform these operations are still emitted.
I doub
Vijaya Kishore Idimadakala wrote:
> ../configure --with-cpu=PowerPC. And it is giving me
> an error during make saying
> "Unknown CPU given in --with-cpu=PowerPC"
gcc-help is a more appropriate place for beginner questions. Try
reading the documentation, e.g.
http://gcc.gnu.org/install/configure.
F. Heitkamp wrote:
> ../../gcc-cvs-3-3/gcc//gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
> /tmp/ccNkOiHW.s: Assembler messages:
> /tmp/ccNkOiHW.s:3142: Error: Unrecognized opcode: `stvx'
You didn't mention the binutils version or how it was configured. It
appears that it isn't completely compatible
Torsten Mohr wrote:
configure: WARNING: No native atomic operations are provided for this \
platform.
configure: WARNING: They cannot be faked when thread support is disabled.
configure: WARNING: Thread-safety of certain classes is not guaranteed.
These are just warnings, and won't stop the bui
Ling-hua Tseng wrote:
> Are there any ways to tell GCC that don't group an jump_insn with
> other insns when structural hazard occured?
Probably multiple ways, depending on what exactly the problem is.
I'd suggest using -da -fsched-verbose=2 and looking at the scheduling
info printed in the sched
Kevin McBride wrote:
I have been having comparison errors while building a native 4.0.1
compiler for my Fedora Core 4 system.
Running
cmp c-pragma.o stage2/c-pragma.o
on your provided files says that they identical. If you are getting
comparison failures on these files, then perhaps your "c
imes creep back in.
See for instance the following ChangeLog entries in the toplevel
ChangeLog file
2004-04-15 James E Wilson <[EMAIL PROTECTED]>
2004-05-25 Daniel Jacobowitz <[EMAIL PROTECTED]>
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Paul Brook wrote:
We already have TYPE_STRING_FLAG used on array types. Maybe it would it make
sense to use that?
That sounds like an excellent choice. dbxout.c and dwarf2out.c already
check TYPE_STRING_FLAG to distinguish strings from arrays.
--
Jim Wilson, GNU Tools Support, http://www.spe
Andrew Haley wrote:
Tom Tromey writes:
> I was under the impression that CHAR_TYPE was deprecated, so I
> purposely avoided it in gcjx. I'm not sure where I got that
> impression though.
I can't remember the context either, but I agree with your memory. I
think it was discussed a little whil
Jerome Guitton wrote:
Two solutions : we can either change the tree code to CHAR_TYPE or add a test
to detect Ada character types in the INTEGER_TYPE case, like it is done for
C:
...
The first solution would probably be cleaner, but it would mean that
Ada would be the only supported langage to us
On Thu, 2005-08-04 at 20:54, Peter O'Gorman wrote:
> 2005-08-?? Peter O'Gorman <[EMAIL PROTECTED]>
> PR 21366
> * gcc.c (process_command): Check the argument to -b has a dash.
> * doc/invoke.texi: Update -b and -V docs.
I checked in the patch.
--
Jim Wilson, GNU Tools Support,
Christian Joensson wrote:
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1plus-checksum.o differs
what does that mean?? the compare passes... and the build continues...
The checksums are used for PCH validatation. We generate md5 checksums
for each cc1 bin
On Thu, 2005-08-04 at 05:41, Peter O'Gorman wrote:
> + trying to interpret the rest of the command line.
> + Use heuristic that all copnfiguration names must have at least
> + one dash '-'. This allows us to pass options starting with -b. */
There is a typo here copnfiguration->confi
Tabony, Charles wrote:
How can I
distinguish recognized from unrecognized insns in ASM_OUTPUT_OPCODE?
Try using the variable this_is_asm_operands.
ASM_OUTPUT_OPCODE is an old macro that doesn't get used much anymore.
FINAL_PRESCAN_INSN is better if you can use it. No recog_data.operand
tric
Jack Howarth wrote:
In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's
compiler I can have a Makefile entry like...
This is PR 21366.
Yo
[EMAIL PROTECTED] wrote:
Recently I tried to install mpich-1.2.7 with gfortran (gcc-4.0.1) on a fedora
core 4 (x86_64) :
The configure for mpich fails for fortran, because getarg and iargc are missing.
Now my question, g77 supported a lot of commonly used service routines, which
are now missing
[EMAIL PROTECTED] wrote:
I guess the combiner generates something like
a trucation pattern when special constant are detected.
The combiner also takse a similiar action in pattern
See the section of the documentation that talks about instruction
canonicalization.
http://gcc.gnu.org/online
Ioannis E. Venetis wrote:
I found that a comment for bug 13756
mentions the missing documentation for -ftree-dse
Should I still create a new bug report?
No. Since we already have one, we don't need another one.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Thu, 2005-07-28 at 16:58, Greg Schafer wrote:
> Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal
> Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal
This is basically what I meant, but I don't want to get in a debate
about what is optimal and what isn't
David Daney wrote:
Recently we experienced the Big-Classpath-Merge. Now most of the source
code for libgcj is maintained in the Classpath project and periodically
copied into the GCC CVS repository.
Appropriate info should be added here:
http://gcc.gnu.org/codingconventions.html#upstream
On Thu, 2005-07-28 at 12:48, David Daney wrote:
> Also you can see that neither hello-world.o nor my libc-2.3.3.so have
> any undefined symbols that would be satisfied by libgcc_s.so.
It looks like you forgot to check the crt*.o files for undefined
references.
If the gcc/glibc toolchain wasn't b
Mark Cuss wrote:
[EMAIL PROTECTED] helloworldsun]$ g++ -b sparc-sun-solaris2.9 hello.cxx
/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/bin/ld:
values-Xa.o: No such file: No such file or directory
collect2: ld returned 1 exit st
How about something like
this?
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
2005-07-28 James E Wilson <[EMAIL PROTECTED]>
* doc/invoke.texi (Wstrict-aliasing=2): Reword.
Index: invoke.texi
===
RCS file: /cvs
Liu Haibin wrote:
to "c". However, it seems very difficult here. The old insn patterns
are all general registers, but the new insn patterns are defined as
custom registers.
The peephole pass does not do register allocation. So you can't use it
to magically change "r" registers to "c" register
Liu Haibin wrote:
(match_operand:SI 2 "register_operand" "r")
But the problem is it uses normal register, like r8, r9. How can I
write the define_peephole2 so that it uses custom registers?
See the "Constraints" section of the documentation. "r" means a general
reg
On Thu, 2005-07-07 at 05:02, Eric Botcazou wrote:
> * config/ia64/hpux.h (MEMBER_TYPE_FORCES_BLK): Only force
> TFmode to BLKmode.
> * config/ia64/ia64.c (force_general_reg): New function.
> (ia64_function_arg): Pass the argument in general regs
> if force_general_reg
On Sun, 2005-07-03 at 07:31, Martin Koegler wrote:
> * need to rewrite recursivly each element of type (which my contain
> structures,
> unions, ...) if a address space is set
> In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as bad
> idea.
It is possible I was wrong. Co
James Kosin wrote:
I'm having problems with building a release.
~make -C gcc gnatlib-shared
http://support.intcomgrp.com/mirror/fedora-core/beta/src/gcc-3.3.6-1.fc1.src.rpm
Neither FC1 nor gcc-3.3 are supported products anymore.
The problem seems to be that ar needs to load the rts/adaint
Stephen Torri wrote:
I am interested in reading the actual grammar files used for parsing C
and C++ programming languages inside gcc. Where are these files located?
See cp/parser.c for the C++ parser. The c-parse files are only for C
and Objective-C.
--
Jim Wilson, GNU Tools Support, http://
On Sun, 2005-07-03 at 09:13, Steve Ellcey wrote:
> I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
> change the mode of a structure containing a single field from BLKmode
> into the mode of the field.
This is why we should be checking types in ia64_function_arg instead of
Mike Stump wrote:
In defaults.h, they do:
/* This is how to output an element of a case-vector that is absolute.
Some targets don't use this, but we have to define it anyway. */
#ifndef ASM_OUTPUT_ADDR_VEC_ELT
#define ASM_OUTPUT_ADDR_VEC_ELT(FILE, VALUE) \
This was added before gcc-2.3.3.
Martin Koegler wrote:
I continued to work on the support for named address spaces in GCC.
This does look like a good start.
An possible issue is the effect on gcc memory usage and compile time. I
see you increased the size of MEM rtl which will increase memory usage.
Also, there seem to be
DJ Delorie wrote:
For some chips, like xstormy16 and m16c, function pointers are wider
than other pointers.
Trying to fake two kinds of pointers when we only have one doesn't seem
wise to me.
A possible solution is to use function descriptors. See FDESC_EXPR and
ASM_OUTPUT_FDESC. So now w
Sergei Organov wrote:
-and functions are removed. This may result in undefined references
+and functions. This may result in undefined references
Thanks. I checked in the patch.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Eric Botcazou wrote:
The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK
macro with this comment:
Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented
the ia64-hpux port. At the time, I mentioned using PARALLELs was a
better solution, but this was a s
Gunther Nikl wrote:
A few LINK_SPEC definitions contain a "%{Wl,*:%*}" sequence.
There is no need to match -Wl options in LINK_SPEC, as it is handled by
the gcc.c driver. The driver support was added in gcc-2.5.8. I believe
all of these LINK_SPEC checks for -Wl are obsolete code from gcc-2.
Vladimir Makarov wrote:
I just hope results
for 64-bit mode, amd machine, or SPECFP2000 are better.
Their web pages primarily talk about the 64-bit performance on AMD
systems. Maybe they aren't well tuned for 32-bit performance and/or
Intel parts. Anyways, from what Daniel Berlin mentioned,
Andrey Belevantsev wrote:
We've also found that current mainline ICEs compiling the testcase with
"-O0 -fschedule-insns -fschedule-insns2".
I suspect this is a bug in ia64_reorg in ia64.c. It shouldn't be trying
to schedule during a non-optimizing compile. So the line
if (ia64_flag_schedu
Steven Bosscher wrote:
Are predicate checks free, or should there be some post-pass to
clean up this kind of useless predication?
On IA-64, predicate checks are free in terms of run-time. There is the
problem that unnecessary predicate checks might increase register
lifetimes, causing extra
Daniel Berlin wrote:
A bunch of random code #ifdef KEY'd
FYI Pathscale was formerly known as Key Research. So the KEY probably
wouldn't mean anything special here, it is likely just a marker for
local changes.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
On Sat, 2005-05-07 at 10:22, Eric Botcazou wrote:
> > Apparently this problem only shows up for x86 when using Sun tools, but
> > when using GNU tools, it also shows up for sparc.
> Do you have a testcase? AFAIK the problem only shows up with the Sun tools.
I meant when using GCC with the Sun ass
On Wed, 2005-05-04 at 16:24, Jeroen Dobbelaere wrote:
> I'm aware of that. The reason are asked for more clarity is that I
> think gcc should
> do better (as in the example I gave), but I want to be sure that this
> is still allowed
> by the standard.
Certainly gcc can and should do better, and th
On Wed, 2005-05-04 at 14:27, Jeroen Dobbelaere wrote:
> Is this correct ?
I was only trying to explain how gcc works for the one example that you
posted. I was not trying to explain precise semantics of how restrict
works according to the ISO C standard, and my message should not be
construed as
Jeroen Dobbelaere wrote:
void test_2(unsigned long* __restrict__ bar, char* __restrict__ bas)
{
unsigned long tmp = *bar;
*bas = 0;
*bar = tmp;
}
The optimization in the first example happens in the postreload cse
pass, and is relying on RTL alias analysis info.
The optimization does not ha
On Wed, 2005-05-04 at 09:37, Anuradha Suraparaju wrote:
> I've attached a sample file to this email. The class defined in the cpp
> file is a cut down and modfied version of the class used in Dirac.
That is a fine bug report. You just need to put it in bugzilla if you
want us to do anything about
On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
> I wonder if the work-in-progress PDP10 port
> (http://pdp10.nocrew.org/gcc/) might help with this.
Interesting, but a hobbyist port for a 36-bit machine that was
end-of-lifed about 2 decades ago has little chance of success, unless
there are some v
Kai Ruottu wrote:
GCC configure. But there are long-standing bugs in the GCC sources and
workarounds/fixes are required.
Since you seem to have an understanding of the problems here, perhaps
you could file some bugzilla bug reports to document them.
then not... As told the "eabi" is not and one
Martin Koegler wrote:
I notice, that your last change in function.c forgets virtual
registers in the RTL in some conditions. In older version (the last I used was
20050412),
this has not happend.
Patches should go to gcc-patches instead of the gcc list.
If you want us to continue accepting patches
Jonathan Bastien-Filiatrault wrote:
* We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On this
DSP, there are two 40-bits accumulators. How do we make GCC take
advantage of this and which machine mode do we use ?
GCC has little support for non-power-of-2 sized accumulators.
Traditionall
Anuradha Suraparaju wrote:
My question is how do I report this as a bug? What information do I
need to provide in the bug report? Did anybody else face similar
problems with GCC-4.0.0 and MMX-enabled programs.
See
http://gcc.gnu.org/bugs.html
for info on reporting bugs.
If you can narrow this d
Satendra Pratap wrote:
I am using a cross compiler "sparclet-aout-gcc". I have written my own
main function and does not link to libgcc's main function while
linking is done. I m not able to initialize the global objects The
generated executable format is "a.out".
You have so much modified stuff he
Dimitri Papadopoulos-Orfanos wrote:
As far as I can understand, it's not possible to build gcc 4.0.0 and gcc
3.4.* using GNU binutils with current release 2.15 of GNU binutils. One
has to use the CVS sources or at least one file.
FYI binutils-2.16 has just been released. You might want to try th
On Fri, 2005-04-29 at 17:29, Amir Fuhrmann wrote:
> 1. If I am ONLY interested in the compiler, and do NOT want to build
> libraries, what would be the process ??
"make all-gcc" will build just the compiler without the libraries.
> 2. I looked at newlib, but wasn't sure of the process of includin
Amir Fuhrmann wrote:
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering... /usr/local/powerpc-eabi/bin/ld: warning:
cannot find entry symbol _start; defaulting to 01800074
Looking at libiberty configure, I see it first tries to get the
by
zouq wrote:
> i found madd instruction in mips.md, but why when i compiled it with
> my cross-compile mipsel-linux-gcc as follows, mipsel-linux-gcc -mips4
> -O2 test.c -S i can`t find any madd instruction in test.s??
Basic questions like this are really more appropriate for the gcc-help
list. The
Amir Fuhrmann wrote:
../gcc-3.4.3/configure --exec-prefix=/usr/local --program-prefix=ppc-
--with-stabs -with-cpu=603 --target=powerpc-eabi --with-gnu-as=ppc-as
--with-gnu-ld=ppc-ld --enable-languages=c,c++
Try adding --with-newlib. You either have to use a combined tree so
that newlib will be a
David Gressett wrote:
The attempt to make HTML documentation crashes:
make[1]: Entering directory `/home/jdg/gccbuild/i686-pc-linux-gnu/libada'
make[1]: *** No rule to make target `html'. Stop.
make[1]: Leaving directory `/home/jdg/gccbuild/i686-pc-linux-gnu/libada'
make: *** [html-target-libada]
Matt Thomas wrote:
I like the more and simplier patterns approach but I'm wondering what
the general recommendation is?
If an optimization pass will re-recog after rewriting an insn, then it
is OK to have two separate patterns for two separate assembly insns.
Otherwise, the optimization pass will
On Wed, 2005-04-27 at 02:44, Andrew Haley wrote:
> Well, of course I'm not going to disagree with you, but I removed the
> assertion because it totally broke the Java front end.
That means you traded a visible compile time error for a possible silent
run-time error. That sounds like a poor trade
On Wed, 2005-04-27 at 12:53, Mike Stump wrote:
> Yes, this is ok. One final nit, if you'd like to fix it as well, is
> that obj-c++ should be added as a non-default language:
Good catch. I fixed that in my patch.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Jean-Paul Rigault wrote:
- I had to use the --enable-languages option to get the Ada compiler;
without it, and contrarily to what is suggested in the installation doc,
Ada was not built.
- the HTML documentation is generated in /objdir//gcc/HTML, not in
/objdir//HTML as indicated in the document
1 - 100 of 262 matches
Mail list logo
