error compiling libgcc with ported cross-compiler
I am porting gcc to a new target architecture, and have come across a
problem when the make process tries to compile libgcc. The error I get
is included below.
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it
only allows (mem (plus (reg ..) (const ..))), and forbids a second
level of memory reference.
I am (obviously) no gcc-expert by far, and have no idea how to tackle
this problem. Has anyone had a similar problem, or any pointers as to
how I can solve it?
The error message is:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
does not satisfy its constraints:
(insn 114 153 117
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1558 (set
(mem/c/i:SI (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -52 [0xffcc])) [0 D.2153+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SI 1 r1)) 3 {*movsi_internal} (nil)
(nil))
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: internal
compiler error: in final_scan_insn, at final.c:2410
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [libgcc/./_powidf2.o] Error 1
make[3]: Leaving directory `/cygdrive/c/home/risc/build/gcc/gcc'
RE: error compiling libgcc with ported cross-compiler
On 10 September 2007 08:55, Tomas Svensson wrote: > I am porting gcc to a new target architecture, and have come across a > problem when the make process tries to compile libgcc. The error I get > is included below. > > It seems that gcc has emitted rtl describing a memory reference (mem > (plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which > should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it > only allows (mem (plus (reg ..) (const ..))), and forbids a second > level of memory reference. > > I am (obviously) no gcc-expert by far, and have no idea how to tackle > this problem. Has anyone had a similar problem, or any pointers as to > how I can solve it? Either step through in a debugger, or bung loads of printfs into G_I_L_A, and see what it does when it gets given a chance to forbid the bad RTL. You might also want to check that LEGITIMIZE_ADDRESS and even LEGITIMIZE_RELOAD_ADDRESS aren't doing anything unsane to it. cheers, DaveK -- Can't think of a witty .sigline today
Re: error compiling libgcc with ported cross-compiler
On Mon, Sep 10, 2007 at 09:54:57AM +0200, Tomas Svensson wrote:
>
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
> does not satisfy its constraints:
> (insn 114 153 117
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1558 (set
> (mem/c/i:SI (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
> (const_int -52 [0xffcc])) [0 D.2153+0 S4 A8])
> (const_int 4 [0x4])) [0 +4 S4 A8])
> (reg:SI 1 r1)) 3 {*movsi_internal} (nil)
> (nil))
It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
--
Rask Ingemann Lambertsen
Re: error compiling libgcc with ported cross-compiler
On 9/10/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
It's really very basic:
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
and in the .c-file:
bool
legitimate_address_p (enum machine_mode mode, rtx addr, bool strict
ATTRIBUTE_UNUSED)
{
return (legitimate_offset_address_p (mode, addr)
|| legitimate_nonoffset_address_p (mode, addr));
}
static bool
legitimate_nonoffset_address_p (enum machine_mode mode
ATTRIBUTE_UNUSED, rtx addr)
{
return (GET_CODE (addr) == REG && REG_OK_FOR_BASE_P (addr));
}
static bool
legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx addr)
{
rtx reg, offset;
if (GET_CODE (addr) != PLUS)
return false;
reg = XEXP (addr, 0);
offset = XEXP (addr, 1);
if ((GET_CODE (reg) == REG && REG_OK_FOR_BASE_P (reg))
&& legitimate_address_integer_p (offset, 0))
return true;
return false;
}
static bool
legitimate_address_integer_p (rtx addr, int offset ATTRIBUTE_UNUSED)
{
return (GET_CODE (addr) == CONST_INT
&& SMALL_INT (INTVAL (addr));
}
/Tomas
Re: Bootstrap failure under Irix
Hi! Sorry for taking so long, but bootstarping really takes forever under SGI (especially as I wasn't getting that much CPU time): I was able to build '128233' sources (see hereafter). Thanks a lot! Philippe PS: the output of check: === gcc Summary === # of expected passes44115 # of unexpected failures43 # of unexpected successes 2 # of expected failures 88 # of unresolved testcases 17 # of untested testcases 35 # of unsupported tests 341 /USER/philippe/Irix/Compilation/Gcc/gcc/xgcc version 4.3.0 20070907 (experimental) [trunk revision 128233] (GCC) Janis Johnson wrote: > > On Thu, 2007-09-06 at 09:47 +0200, Philippe Schaffnit wrote: > > Hi! > > > > I am seeing the folowing bootstrap failure under SGI Irix: > > > /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function > > 'gen_fixuns_truncdfsi2': > > /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2808: error: too > > few arguments to function 'real_2expN' > > > My last attempt at wa succesful with : '4.3.0 20070823 (experimental) > > [trunk revision 127728]' (I haven't tried in between). Can anyone > > suggest anything? > > I broke this, and reverted the patch (and two other patches that cleaned > up after it) in r128193. > > Janis
Re: [RFC] Marking C++ new operator as malloc?
Hi, On Sun, Sep 09, 2007 at 12:56:25PM -0700, Mark Mitchell wrote: > For a particular implementation of "operator new" (such as the one in > libstdc++), you can of course make it safe in the same way as "malloc"; > hide the implementation somewhere the rest of the program can't see it > (modulo LTO). But, to declare it with the "malloc" attribute in the > headers seems dangerous, since we have no way of knowing if the user > replaced it, off in some file somewhere we don't know about, but in such > a way that pointers in our source code are being laundered back to us. All I attempted to do was to mark just one particular implementation of the new operator which also happened to be the default built-in one. From my experiments, it appears that marking it as malloc in the libstc++ headers does not affect other implementations. However, as Gabriel Dos Reis correctly pointed out, the attribute is not applied to the new operator if the changed declaration is not somehow included in the compiled source. Fixing this inconsistency requires some changes in the FE. Nevertheless, so far I do not see problems with declaring standard new implementation as malloc in the header file. I hope you all agree that marking the default (and only the default), implementation as malloc is worthwhile and will look into it(, even though it is going to take some time). Martin
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: > We are closing in on Stage 3, previously announced for September 10th. > At this point, I'm not aware of any reason to delay that date. Are > there any Stage 2 patches that people don't think will be submitted by > that point? > > Are there Stage 1 or Stage 2 patches in need of review? I'll do my best > to either (a) convince someone to review them, or (b) review them myself. I have a bunch of tiny patches, nevertheless all Stage 2 material, as they add new features: __artificial__ attribute (except the builtins.c hunk which is addressed differently): http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html __builtin_va_arg_pack_len () addition: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html redundant zero store elimination optimization (simplistic version, but nevertheless is able to trigger many times during gcc bootstrap): http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html diagnostic changes to print virtual call stack: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html __error_decl__ and __warning_decl__ attributes: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html Jakub
Re: [RFC] Marking C++ new operator as malloc?
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: Mark> If the compiler treats: Mark> int *p = new int; Mark> any differently from: Mark> int &r = *new int; Mark> then we're missing an optimization opportunity. AFAIK we don't have a way to mark a function as "cannot return NULL". This is PR 20318. Tom
RE: GCC 4.3.0 Status Report (2007-09-04)
>Jagasia, Harsha wrote: > >> I still plan to submit a patch for the x86 target cost model tuning. > >Assuming that this isn't too dramatic, I'll leave approval of that >during Stage 3 to the x86 back-end maintainers. Thanks. The patch involves some x86 back-end bits, which Honza has already approved and some fixes to the vectorizer, which Dorit has mostly approved (I am waiting on her approval for my last mail). My plan is to submit the patch today with the changes Dorit has recommended. I may end up splitting it such that most of the patch makes it today and one bug fix for the vectorizer makes it in stage 3. >Thanks, > >-- >Mark Mitchell >CodeSourcery >[EMAIL PROTECTED] >(650) 331-3385 x713 >
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote: > Are there Stage 1 or Stage 2 patches in need of review? I'll do my best > to either (a) convince someone to review them, or (b) review them myself. It has only been four days since I posted the patch, but I am waiting for a review of the new interference graph representation: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html In addition to the powerpc64-linux bootstrap and regtesting I did, Seongbae bootstrapped and regtested this on x86_64 with no regressions as well as running it on SPEC with no runtime or compile time regressions. Peter
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: > Summary > === > > We are closing in on Stage 3, previously announced for September 10th. > At this point, I'm not aware of any reason to delay that date. Are > there any Stage 2 patches that people don't think will be submitted by > that point? > > Are there Stage 1 or Stage 2 patches in need of review? I'll do my best > to either (a) convince someone to review them, or (b) review them myself. > > Quality > === > > Priority # > --- > P1 43 > P2118 > P3 4 > Total 165 > > Obviously, that's rather more P1s than we'd like. As I mentioned in my > previous status report, of particular concern is that we've got a lot of > 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we > still need to go and fix them. > > I'm concerned about getting into a situation where we say "well, 4.2 has > some bugs, but all of those are fixed in 4.3" and then realize that "oh, > well, 4.3 has different bugs too, but those are all fixed in 4.4" and so > forth. One patch that got dropped on the floor was my patch to remove the dependency in the back ends of the way arguments are encoded, so that eventually for LTO we can swtich to using a vector instead of linked list. As I recall, I had fixed all backends except for the SPU, which I needed to investigate the builtins. Now that SSE5 is winding down, I can go back to this patch. Given it has been reviewed in this list, I will leave it to Mark to decide whether it should go into 4.3 or 4.4. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: [RFC] Marking C++ new operator as malloc?
On 9/10/07, Tom Tromey <[EMAIL PROTECTED]> wrote: > > "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: > > Mark> If the compiler treats: > Mark> int *p = new int; > Mark> any differently from: > Mark> int &r = *new int; > Mark> then we're missing an optimization opportunity. > > AFAIK we don't have a way to mark a function as "cannot return NULL". > This is PR 20318. If someone reviewed zdenek's function attribute table patch (That started adding info about arguments, etc and what happens to them), we could simply extend it to do this in about 10 lines of code > > Tom >
deadline extension for debug info project into GCC 4.3 stage3?
On Aug 9, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > We entered Stage 2 on July 6th. I plan to put us into Stage 3 on > September 10th. At that point, we will accept only bug-fixes -- no > more new features until Stage 1 for GCC 4.4. I was hoping I'd have the new debug info infrastructure, based on annotations carried all the way from the source code, ready in time. Even though I already have code to introduce the annotations in the tree representation, only when generating debug information, and to carry them over all the way to rtl var-tracking, without any changes whatsoever to the generated code on x86_64-linux-gnu. I have already written (over this past weekend) some code in var-tracking to use these annotations to generate improved debug info notes, but this last part still needs some work. I think it would be nice to offer this new debug info generation machinery, at least as an option, in GCC 4.3, so I'd like to request some more time to make it fully functional before I post the very large patches. Making it optional and disabled by default would make it very non-intrusive and safe for stage3, in spite of the patch size, and would enable a wider audience to give it a try and report problems and opportunities for improvement. I'm already aware of many of these, but I'm not yet at a point in which I can compare the quality of the generated debug info. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: GCC 4.3.0 Status Report (2007-09-04)
Hi, thanks for looking at the patch. On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote: > Martin Jambor wrote: > > > Well, there's mine :-) Specifically, its the "Switch initializations > > conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html > > Do you have an FSF copyright assignment on file? This patch is big > enough that we would not be able to include it without that. Yes, I do, see http://misc.jamborm.net/Jambor305799.pdf > I see one technical change that should be made. In particular, please > change: > > > +/* We never create arrays larger than the following constant (given in > > number > > + of elements). */ > > +#define MAX_ARRAY_RANGE 0x2000 > > + > > +/* We never create arrays if the number of branches is not at least the > > range > > + divided by the following constant. */ > > +#define MAX_RANGE_BRANCH_RATIO 8 > > to use the --param mechanism. Our policy is to have *no* magic numbers > for these kinds of things. It's easy enough to allow users to use > --param to set the values, and that makes it easy for people (often the > compiler developers themselves) to experiment with the values to help > fine-tune the defaults. OK, I have changed the patch accordingly (and added some documentation that was missing last time) and am currently re-testing it. I expect to post the new version to the list tonight. Martin
Re: error compiling libgcc with ported cross-compiler
Tomas Svensson wrote: It seems that gcc has emitted rtl describing a memory reference (mem (plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it only allows (mem (plus (reg ..) (const ..))), and forbids a second level of memory reference. This is probably a REG_OK_STRICT bug. During reload, an unallocated pseudo-reg is actually a memory reference in disguise, so you must check for and reject pseudo-regs during reload. This is handled by the REG_OK_STRICT macro. Just look at any port to see how to handle this correctly. Jim
gcc-4.1-20070910 is now available
Snapshot gcc-4.1-20070910 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070910/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 128352 You'll find: gcc-4.1-20070910.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070910.tar.bz2 C front end and core compiler gcc-ada-4.1-20070910.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070910.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070910.tar.bz2 C++ front end and runtime gcc-java-4.1-20070910.tar.bz2 Java front end and runtime gcc-objc-4.1-20070910.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070910.tar.bz2The GCC testsuite Diffs from 4.1-20070903 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: error compiling libgcc with ported cross-compiler
On Mon, Sep 10, 2007 at 12:22:11PM +0200, Tomas Svensson wrote:
> static bool
> legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx
> addr)
> {
> rtx reg, offset;
>
> if (GET_CODE (addr) != PLUS)
> return false;
>
> reg = XEXP (addr, 0);
> offset = XEXP (addr, 1);
>
> if ((GET_CODE (reg) == REG && REG_OK_FOR_BASE_P (reg))
> && legitimate_address_integer_p (offset, 0))
> return true;
>
> return false;
> }
I think Jim is right: The "GET_CODE (reg) == REG && REG_OK_FOR_BASE_P
(reg)" part doesn't do what you hope it does. You will have to pass down the
"strict" parameter all the way from legitimate_address_p(), use
REG_P (reg) && (!strict || REG_OK_FOR_BASE_P)
and additionally,
#ifdef REG_OK_STRICT
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
#else
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, false)) goto ADDR; }
#endif
but you'll have use the strict version of REG_OK_FOR_BASE_P(), normally by
defining REG_OK_STRICT before including machine.h.
When your addresses are as simple as yours, all this is easier to do
directly in machine.h. The standard way is to define your helper macros
differently depending on REG_OK_STRICT:
#ifdef REG_OK_STRICT
#define REG_OK_FOR_BASE_P(x) \
(REGNO_OK_FOR_BASE_P (REGNO (x)))
#else /* !REG_OK_STRICT */
#define REG_OK_FOR_BASE_P(x) \
(!HARD_REGISTER_P (x) || REGNO_OK_FOR_BASE_P (REGNO (x)))
#endif
Then define GO_IF_LEGITIMATE_ADDRESS() using REG_OK_FOR_BASE_P().
There's a little bit of trickery with the non-strict REG_OK_FOR_BASE_P()
macro. If you port has virtual hard regs used in addresses (e.g. a
non-existant argument pointer, which is later eliminated into the frame
pointer or the stack pointer), then you have to allow those also.
> static bool
> legitimate_address_integer_p (rtx addr, int offset ATTRIBUTE_UNUSED)
> {
> return (GET_CODE (addr) == CONST_INT
> && SMALL_INT (INTVAL (addr));
> }
GET_CODE (x) == REG --> REG_P (x)
GET_CODE (x) == CONST_INT --> CONST_INT_P (x)
--
Rask Ingemann Lambertsen
Re: GCC 4.3.0 Status Report (2007-09-04)
Jakub Jelinek wrote: > I have a bunch of tiny patches, nevertheless all Stage 2 material, as > they add new features: I'd like a middle-end maintainer to review this one: > redundant zero store elimination optimization (simplistic version, > but nevertheless is able to trigger many times during gcc bootstrap): > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html That seems like a nice optimization. It was interesting to see how many places this hit in GCC. I didn't see any data about performance improvements on benchmarks (e.g., SPEC), or code-size improvements (e.g., CSiBE), but it sure can't hurt. Unfortunately, I think there are enough issues around most of the rest of these patches that we should wait for 4.4. In particular, all of these: > __artificial__ attribute (except the builtins.c hunk which is addressed > differently): > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html > > __builtin_va_arg_pack_len () addition: > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html > > __error_decl__ and __warning_decl__ attributes: > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html add extensions of one kind or another to GCC, and there has been some discussion about each of them. I think we have to be very careful with these things; once they go out in a release, we live with them forever. However, I do hereby acknowledge that these were submitted before Stage 2 ended, and, as per our guidelines, if these patches are approved, they can still go in. This one: > diagnostic changes to print virtual call stack: > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html looks like it would have a major effect on consumers of GCC output. As you say: > The tools that parse this will need changing anyway to do something > reasonable with it I think we should consider GCC diagnostic a defined, machine-readable format and that we should modify it only in backwards-compatible ways. Or, make incompatible changes only under control of an option or environment variable. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: deadline extension for debug info project into GCC 4.3 stage3?
Alexandre Oliva wrote: > I think it would be nice to offer this new debug info generation > machinery, at least as an option, in GCC 4.3, so I'd like to request > some more time to make it fully functional before I post the very > large patches. Thank you for letting me know. > Making it optional and disabled by default would make it very > non-intrusive and safe for stage3, in spite of the patch size, and > would enable a wider audience to give it a try and report problems and > opportunities for improvement. That's a possibility, but I don't want to commit at this point. We can have a look at it when you submit it and decide. However, in general, introducing churn for the sake of a feature that will be off by default isn't something that I would want to do. The more compartmentalized you make it, the better your chances are. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Peter Bergner wrote: > On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote: >> Are there Stage 1 or Stage 2 patches in need of review? I'll do my best >> to either (a) convince someone to review them, or (b) review them myself. > > It has only been four days since I posted the patch, but I am > waiting for a review of the new interference graph representation: > > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html This certainly seems an excellent thing. If nobody else reviews this, I will do so -- but I hope that one of our busy middle-end maintainers will make time. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] Marking C++ new operator as malloc?
Richard Guenther wrote:
> Well, we have that now:
>
> int *q = new int;
> delete q;
> int *p = new int;
> delete p;
> if (q != p)
> cout << "different";
>
> we cannot optimize the test to be always true. The point is that alias
> analysis tells us something about accesses to *q and *p, but neither
> on lifetime of *q and *p nor lifetime of q and p (and thus their value).
That's an interesting example. Thanks for showing it to me. From
looking at the standard, I think I could be a language lawyer and try to
argue that the comparison is not defined -- but that would just be
weaselish; the comparison should be defined. So, yes, I concede that
you've found a counter-example to my claim that "*p does not alias *q"
=> "p != q". How odd. I would have to revise my claim to require that
"p" and "q" are valid pointers.
So, for something like:
char *pool;
void *operator new[] (size_t s) { /* return memory from pool */ }
...
pool = new char[1024];
char *c = new char[16];
IIUC, your claim is that if pool and c now have the same value, then any
indirection through pool is invalid (because the object with newest
lifetime at that location is the 16-byte array), so we can assume *pool
and *c do not alias? Do you also claim that:
((char (*)[16])pool)[0] = '\0';
is invalid because it is a pointer "based on" pool?
If you think it's OK to put the "malloc" attribute on operator new, why
did you say earlier that you can't implement "malloc" in C itself, for
exactly these kinds of reasons? Isn't the situation exactly analogous?
I think I'm getting confused. Perhaps you could sum up in a single
email the argument for why putting this attribute in our standard
headers is safe, even in view of possible replacement in user programs?
Sorry,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: error compiling libgcc with ported cross-compiler
Thanks a lot for your input, I think I understand some of that code better now.
I stumbled upon a solution last night, on realizing that the problem
was with the DFmode powidf2 and seeing that I had not defined the
movsf or movdf insns (because I thought I shouldn't need them, having
no HW floating point support).
Defining them solved the problem, but now I have a very similar one
with the complex arithmetic __mulsc3 function in libgcc:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
This time I'm not sure what to do though. Do I really have to define
complex movsc-insns? I haven't found any other ports doing that, so
I'm guessing there's something else I'm missing.
