Re: Bug in the specs or bug in the code?
On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote: In the Linux Standard specs in http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html it is written in the specification of the FDE (Frame Description Entry) the following: I suggest you report this problem to the LSB, since they wrote that documentation. The documentation is incorrect. -- Daniel Jacobowitz CodeSourcery
Re: How to insert dynamic code? (continued)
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote: So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Yes but then it stops there instead of going upwards and finding the catch! It is as my insertion left the list of registered routines in a bad state. I will look again at this part (the registering part) and will try to find out what is going on. It sounds to me more like it used your data, and then was left pointing somewhere garbage, not to the next frame. That is, it sounds like there's something wrong with your generated unwind tables. That's the usual cause for unexpected end of stack. -- Daniel Jacobowitz CodeSourcery
Re: Bug in the specs or bug in the code?
On Thu, Jul 13, 2006 at 05:10:19PM +0200, jacob navia wrote: Mmmm report this problem to the LSB. Maybe you have someone there I could reach? An email address? There is no feedback or bugs button in their page. Try http://www.freestandards.org/en/LSB - lsb-discuss mailing list? -- Daniel Jacobowitz CodeSourcery
Re: How to insert dynamic code? (continued)
On Thu, Jul 13, 2006 at 11:21:04AM -0700, Seongbae Park wrote: The above code looks incorrect, for various reasons, not the least of which is that you're assuming CIE/FDE are fixed-length. There are various factors that affect FDE/CIE depending on PIC/non-PIC, C or C++, 32bit/64bit, etc - some of them must be invariant for your JIT but some of them may not. Also some of the datum are encoded as uleb128 (see dwarf spec for the detail of LEB128 encoding) which is a variable-length encoding whose length depends on the value. In short, you'd better start looking at how CIE/FDE structures are *logically* layed out - otherwise you won't be able to generate correct entries. I highly highly recommend finding a way to dump your CIE/FDE structures to an ELF file, so that you can use readelf to view them. It is quite accurate and matches the GCC implementation closely. If it can't dump your FDEs, we probably won't unwind through them either. -- Daniel Jacobowitz CodeSourcery
Re: [PATCH] Install drivers from gcc/Makefile.in
On Thu, Jul 13, 2006 at 09:41:45PM -0300, Rafael Espíndola wrote: The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ - g++ links remains in the Make-lang.in Ok for trunk when stage1 starts? Please send patches only to the gcc-patches mailing list. TIA. -- Daniel Jacobowitz CodeSourcery
Re: gcc visibility used by moz
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote: No, that's why we need programmer provided attributes. The programmer says: the client code needs to know about the existence of this type so it can get pointers and references to instances and pass them back in later and maybe be able to call virtual member functions and access non-static members by putting it in a header which they document should be included by client code - thus client code includes it and knows about the type. But the programmer says: it is documented that the member functions and static members of this type should not need to be accessed outside of the shared object that I will define by use of the linker later on - nor should its constructors/destructors need to be called from outside that shared object, except maybe *this* one and *that* one. Thus the symbols used to lookup those things do not need to be exported from the shared object. I just don't get it. Why should it matter whether a member function is virtual or not in order to be able to call it from outside this shared object? Either you can access the public members of the class, or you can't. Being able to access some of them and get link errors on others is a very strange default interpretation. -- Daniel Jacobowitz CodeSourcery
Re: gcc breakage
On Mon, Jul 10, 2006 at 01:34:12PM -0700, Steve Kargl wrote: It's my understanding that every change requires a ChangeLog entry. There is now no consistent record of the difference between 115310 and 115311 without actually looking at svn log fixincludes/Makefile.in. Perhaps, a quick question on IRC of the correct protocol is appropriate? It is fairly typical to omit the changelog entry in fix my last patch commits. Also in fix the ChangeLog commits. -- Daniel Jacobowitz CodeSourcery
Re: Running aclocal in libstdc++-v3 directory
On Mon, Jul 10, 2006 at 03:14:36PM -0700, Steve Ellcey wrote: I am trying to make a configure change in the libstdc++-v3 directory but when I run aclocal (even on an unmodified libstdc++-v3 directory from the top-of-tree), I get an error message. Does anyone else see this? My rule of thumb: Check the options in automake's generated Makefile.in. You probably need a -I path. -- Daniel Jacobowitz CodeSourcery
Re: A question about TYPE_ARG_TYPES
On Wed, Jul 05, 2006 at 11:49:58AM -0400, Daniel Berlin wrote: I believe it also happens with varargs functions in some cases, if there was nothing but a varargs parameter. I was recently reminded that that's not valid C. Is there any language which lets you get away with only unnamed arguments? If not, I suspect this is only for old-style definitions. -- Daniel Jacobowitz CodeSourcery
Re: gcc 4.2 more strict check for function called through a non-compatible type
On Wed, Jul 05, 2006 at 09:11:32AM -0700, Andrew Pinski wrote: What happens when a target comes along and passes different pointers types differently. Like say a floating point pointer in the FP register and an pointer to an integer in the general purpose register, wouldn't that also break the code in question? Yes this is in theory but still saying we are breaking existing working code is bogus in this case. The above reason is one of the reasons why this code is undefined because it does not make sense. This is a flawed argument. Ian said this could would work, and we are gratuitously breaking it. Responding I can conceive of a hypothetical target where it would not be portable doesn't mean anything. If what you really meant to say was casting between a int (*)(double) and int (*) (char *), then yes, that won't work. But there's plenty of other ways to write valid code that won't work! Is it really working after all is the real question and I say no it can never work correctly on any target. Obviously untrue. I can't imagine a plausible target where int (*) (char *) and int (*) (unsigned char *) would not be compatible, for instance. -- Daniel Jacobowitz CodeSourcery
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 11:20:00AM -0600, Shaun Jackman wrote: Hello Richard, Dan, I'm trying to track down which part of the GCC source tree makes the decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation. A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a reference to a static function. I thought there was a good chance one of you two might have added this feature. If you're familiar with the the patch, would you please point me to the relevant ChangeLog entry? I'm hoping to add an exception for execute in place (XIP) code (-fPIC -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32. GOTOFF support has been there for a long while. Only use of it for static functions is recent. It should be easy to find. But this is not at all the only problem. GCC's PIC model assumes a fixed displacement between segments. We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. -- Daniel Jacobowitz CodeSourcery
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. Any chance of this work making it into GCC? Yes - but we haven't had time to submit it. -- Daniel Jacobowitz CodeSourcery
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote: On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. Do you know who added this feature? What is you, or perhaps Nick Clifton or Richard Earnshaw? If I could find the person and the file that added this feature, I could probably track down the patch in svn and modify it for XIP. It was probably me. But why can't you do this yourself? Look at the assembly. See what the output string is. Search for it in config/arm/. Use svn blame, as already suggested. -- Daniel Jacobowitz CodeSourcery
Re: unable to detect exception model
On Sun, Jun 25, 2006 at 07:59:14PM +0200, Richard Guenther wrote:
pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
I learned while working on the zone collector that there is at least
one platform where this doesn't work, because long double had an
alignment of eight on its own and four as a structure field. It might
have been powerpc-darwin.
--
Daniel Jacobowitz
CodeSourcery
Re: unable to detect exception model
On Sun, Jun 25, 2006 at 11:19:45AM -0700, Andrew Pinski wrote:
Maybe the struct should be rewritten like:
struct max_alignment {
char c;
union {
long double d;
HOST_WIDEST_INT i;
} u;
};
To make sure the long double was first which is usually the cures the
whole struct
alignment issues.
It's a union. If that makes a difference the platform ABI is
hopelessly broken.
Anyway, I'm thinking of MAX_FIELD_ALIGNMENT or something like that.
--
Daniel Jacobowitz
CodeSourcery
Re: Project RABLET
On Fri, Jun 23, 2006 at 04:30:01PM -0400, Robert Dewar wrote: However, RABLET is not writing a register allocator so its moot anyway :-). indeed, moot = disussable, undecided, so here we are discussing (or if you like to use the verb, mooting) the issue. Please try the other definition, which he clearly meant: 2. Of purely theoretical or academic interest; having no practical consequence; as, the team won in spite of the bad call, and whether the ruling was correct is a moot question. -- Daniel Jacobowitz CodeSourcery
Re: !(fun) with tls
On Fri, Jun 23, 2006 at 12:30:22AM +0530, Niklaus wrote: i think this is something to do with --with-sysroot. Try removing the sysroot but i am not sure well sysroot/lib should contain libc.so /lib/libc.so.6 is provided by glibc whereas /usr/lib/libc.so is provided by glibc-devel. Maybe some one experienced can help you out. Don't crosspost to gcc and gcc-help, please. This is not a question about GCC development. -- Daniel Jacobowitz CodeSourcery
Re: MIPS RDHWR instruction reordering
On Fri, Jun 16, 2006 at 02:12:29PM -0700, Ian Lance Taylor wrote: The computation of the address of x was moved outside the conditional--that is, both the rdhwr and the addu moved. You'll have to figure out why. gcc shouldn't move instructions outside of a conditional unless they are cheap and don't trap. This instruction doesn't trap, but it's not cheap. What metric gets used for this - rtx_cost? -- Daniel Jacobowitz CodeSourcery
Re: Code Flow for RTL generation
On Thu, Jun 15, 2006 at 10:05:10AM -0400, Robert Dewar wrote: You don't need to undo side effects for debugging purposes, you just need to be able to recreate previous states from the point of view of the application. So for I/O operations, you need to restore memory to the state before the I/O operation, but you don't have to try to somehow undo the external effects of the program, so I don't call that a restriction at all. Not really. If you want to be able to back up and try things differently, you need to be able to at least change file seek offsets. Fortunately GDB has code to do this nowadays! It can create checkpoints and go back to them later. It doesn't have an actual reverse debugging implementation yet - but it's been proposed. The point of going backwards (a feature quite familiar to me from the use of hardware debuggers on PC's in bygone years) is to figure out what went wrong, and for that purpose you only need to worry about the machine/memory state. Not when you're debugging userspace and you have files. -- Daniel Jacobowitz CodeSourcery
Re: Code Flow for RTL generation
On Thu, Jun 15, 2006 at 10:31:55AM -0400, Robert Dewar wrote: Daniel Jacobowitz wrote: The point of going backwards (a feature quite familiar to me from the use of hardware debuggers on PC's in bygone years) is to figure out what went wrong, and for that purpose you only need to worry about the machine/memory state. Not when you're debugging userspace and you have files. I just don't see that at all, if you can back up to previous memory states, where the entire machine state is reproduced that's good enough. Well, of course. But we're talking about different concepts. You're talking about something that involves total I/O replay, which requires exclusive control of a piece of physical hardware. GDB will, and some other debuggers already do, support doing this entirely unprivileged, at a process level on Unix-like systems. -- Daniel Jacobowitz CodeSourcery
Re: Generator programs can only be built with optimization enabled?
On Mon, Jun 12, 2006 at 10:22:17AM -0400, David Edelsohn wrote: Typing make in the gcc subdirectory does not do what I expect. Then could you clarify what happens, and what you expect, please? -- Daniel Jacobowitz CodeSourcery
Re: Thoughts about GC root sets
On Wed, Jun 07, 2006 at 06:57:45PM +0200, Laurynas Biveinis wrote: As far as I can understand, current GGC-ors do not simply register them as a additional roots - they walk them all the way down by the pointers and mark stuff as required during collection. Now, if I add the roots to Boehm's GC, this traversal and marking will be done internally by Boehm's GC. The question is, does GCC have any data structures looking like this: root - some GC'ed memory - some malloc'ed memory - some GC'ed memory (or similar)? Such cases should be OK with current GGC schemes, No, it wouldn't be. The collector would try to mark the malloced memory, and blow up. -- Daniel Jacobowitz CodeSourcery
Re: [RFC] Optimization Diary
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote: And string does not answer localization issue, however for numbers at least there is one precedent to follow. I think this discussion has gotten totally sidetracked. When I said I was in favor of strings, I didn't mean messages that would ever be displayed! It's the difference between DW_TAG_compile_unit and compile-unit. It is no more work for the producer or for the consumer, it's clearer, and conflicts are much less likely. The only downside is that it's larger. But with string duplicate elimination - your linker can do that, I hope - it's only larger by a trivial amount. -- Daniel Jacobowitz CodeSourcery
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote: Devang Patel [EMAIL PROTECTED] writes: | [ Interestingly, there is a long standing request, here at Apple, to list | command line options in object file (even when optimization is not used). | One of our intern tried to put them in STABS string. It may be a good | idea to use DWARF in that case also. However it is orthogonal to | optimization diary. It is a good small project, if someone is | interested. ] I was under the impression that it was sort tkane care of by some patches from CodeSourcery. Though, it is possible I may have dreamted. Nope, it was Nick. -- Daniel Jacobowitz CodeSourcery
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote: I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. In practice, using string identifiers does make conflicts less likely. It's also easier for a vendor to pick a unique prefix and be confident that Apple isn't going to assign some other meaning to csl-inline-bart. -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote: Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. If one compiled everything with -fexceptions, could you then use the ARM ABI EH unwind stuff? Or, is there just no way to do this in the ARM EABI? The DWARF unwinding tables are descriptive; you can interpret them however necessary, for unwinding or for backtraces. But the ARM unwinding tables are more opaque. You have to call the personality routines in order to do anything. I don't believe there's a way to get runtime backtraces from them, reliably. It might be possible to implement _Unwind_Backtrace, but it also might require additional changes similar to those we needed for forced unwind. -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
On Fri, Jun 02, 2006 at 04:20:21PM +0100, Richard Earnshaw wrote: On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote: However when dealing with __builtin_frame_address, we must return the correct value from this function no matter what the value of count. This patch therefore forces use of a hard FP in such situations. Eh? The manual explicitly says that __builtin_frame_address is only required to work if count=0. You simply cannot up walk arbitrary numbers of frames on some CPUs since code isn't compiled to support it. Right - it's the result of __builtin_frame_address (0) we're looking at here. Mark's latest change seems logical to me: the user has asked for the frame address, so hadn't we better arrange that there's a frame? -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote: On Fri, 2006-06-02 at 16:28, Paul Brook wrote: I agree that in general you need ancillary information way to get a backtrace on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer then you can walk the frames. Given this assumption I think it make sense to have _b_f_a(0) force the use of a frame pointer. No, in the general case you can't. Because ARM and Thumb frames are laid out differently. In ARM code the frame pointer is in r11 (when not eliminated); in thumb code it is in r7 (because r11 can't be used in memory insns). I'm reading these two paragraphs and the two of you seem to be in violent agreement. Paul assumed ARM code only. -- Daniel Jacobowitz CodeSourcery
Re: Suggestion for logging changes on Bugzilla
On Wed, May 31, 2006 at 02:03:41PM -0500, Bradley Lucier wrote: I would like to suggest that all substantive changes to a bugzilla record (change of title, change of component, change of Reported against, etc.) be automatically accompanied by a log entry in the PR that states the change and who made it. Then we can at least have a record of who made changes and be able to ask them why there were made, etc.. I think e-mail is now sent to interested parties when such changes are made, but it would be good if a record is kept in the PR, too. It already is. Click View Bug Activity. -- Daniel Jacobowitz CodeSourcery
Re: IA-64 speculation patches have bad impact on ARM
On Tue, May 30, 2006 at 08:57:57PM +0200, Paolo Bonzini wrote:
int
default_reorder2 (FILE *dump ATTRIBUTE_UNUSED,
int sched_verbose ATTRIBUTE_UNUSED,
rtx *ready, int *pn_ready,
int clock_var ATTRIBUTE_UNUSED)
{
int n_ready = *pn_ready;
/* This is correct for sched-rgn.c only. */
if (reload_completed
(flag_sched2_use_superblocks || flag_sched2_use_traces))
return 0;
if (n_ready 1)
{
basic_block bb = BLOCK_FOR_INSN (current_sched_info-prev_head);
if (BLOCK_FOR_INSN (ready[n_ready - 1]) != bb)
{
int i;
for (i = n_ready - 1; i = 0; i--)
{
rtx insn = ready[i];
if (BLOCK_FOR_INSN (insn) != bb)
continue;
memcpy (ready + i, ready + i + 1,
(n_ready - i - 1) * sizeof (*ready));
ready[n_ready - 1] = insn;
break;
}
}
}
return 0;
}
Not even a single comment - shame on you both! :-) If this is the
solution we choose, can we make sure that there's at least a comment
explaining what's going on?
--
Daniel Jacobowitz
CodeSourcery
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Tue, May 30, 2006 at 09:03:54PM +0100, Paul Brook wrote: I found arm.md and the moveqi insns, but because of the different addressing modes of strb and swpb, its not easy to make the change. And there must be a compiler option for this, too. Could somebody please tell me how to implement this change? Short answer is probably not. There are a couple of complications that spring to mind. The different addressing modes and the fact that swp clobbers a register are the most immediate ones. You'll need to modify at least the movqi insn patterns, memory constraints and the legitimate address stuff. I'm not sure about the clobber, that might need additional reload-related machinery. I suspect it would be better to make GCC do halfword stores instead (read/modify/write). -- Daniel Jacobowitz CodeSourcery
Re: Can't commit to gcc-4.1
On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote: Is anything wrong with SVN, or did my authorization to commit somehow fall through the cracks? Is it maybe an anonymous checkout? Check svn info. -- Daniel Jacobowitz CodeSourcery
IA-64 speculation patches have bad impact on ARM
Hi Maxim and Vlad,
I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
The testcase is attached; an arm-linux-gnueabi compiler should be able to
reproduce it with -p -O2. The failure is inability to find two consecutive
registers to hold a DImode value. The cause is roughly like this:
DImode add;
if (({complicated asm with many local register variables}))
return 0;
The register variables get lifted out of the if statement and moved before
the add, thus occupying basically all available hard registers.
If it were just that, I might try to cobble around it in glibc. But there's
actually another layer:
if (DImode compare)
{
DImode add;
if (({complicated asm with many local register variables}))
return 0;
...
}
The register variables and their initializations get hoisted all the way out
of the first if. On ia64, with a million execution units to spare and a
fat pipeline, this may make sense. On targets with a simpler execution
model, though, it's pretty awful. If the condition (which we have no
information on the likelihood of) is false, we've added lots of cycles for
no gain. It's not like the scheduler was filling holes; the initializations
were scheduled as early as possible because they had no dependencies.
With the parameter turned back down to one, the testcase compiles, and the
code looks sensible again. No, I wasn't able to work out why profiling was
necessary to trigger this problem; I suspect it makes some register
unavailable, but I'm not sure which. I didn't look into that further.
What's your opinion? We could easily change the default of the parameter
for ARM, but I assume there are other affected targets. I don't know if we
need the extended region scheduling to be smarter, or if it should simply be
turned off for some targets.
--
Daniel Jacobowitz
CodeSourcery
typedef union
{
struct
{
int __lock;
unsigned int __futex;
__extension__ unsigned long long int __total_seq;
__extension__ unsigned long long int __wakeup_seq;
} __data;
}
pthread_cond_t;
__pthread_cond_signal (cond)
pthread_cond_t *cond;
{
if (cond-__data.__total_seq cond-__data.__wakeup_seq)
{
++cond-__data.__wakeup_seq;
if (!__builtin_expect (({
do { } while (0);
long int __ret;
__ret = ({
register int _a1 asm (r0), _nr asm (r7);
register int _v2 asm (v2) = (int)(((4 24) | 1));
register int _v1 asm (v1) = (int)((cond-__data.__lock));
register int _a4 asm (a4) = (int)((1));
register int _a3 asm (a3) = (int)((1));
register int _a2 asm (a2) = (int)(5);
_a1 = (int) ((cond-__data.__futex));
_nr = ((0 + 240));
asm volatile (swi 0x0 @ syscall SYS_ify(futex)
: =r (_a1)
: r (_nr), r (_a1), r (_a2),
r (_a3), r (_a4), r (_v1), r (_v2)
: memory);
_a1;});
__ret;}), 0))
return 0;
}
}
Re: PATCH: Update src/intl from gcc/intl
On Fri, May 19, 2006 at 04:54:17PM +0100, Nick Clifton wrote: Hi Steve, OK, Here is an official patch proposal to replace the contents of the src/intl tree with the bits from gcc/intl. 2006-05-19 Steve Ellcey [EMAIL PROTECTED] * MAINTAINERS: Change intl updating instructions. * config.rpath: Copy from GCC tree. * intl: Replace contents of intl directory with intl from GCC tree. Approved for binutils. Fine for GDB, too. -- Daniel Jacobowitz CodeSourcery
Re: intl directory: gcc vs. src
On Tue, May 16, 2006 at 03:36:22PM -0700, Steve Ellcey wrote: Can someone tell me about this automatic merge? I was going to submit a formal patch to change the contents of src/intl but it seems that if we have an automatic merge to copy libiberty from gcc to src, we could do the same for intl (and src/config.rhost) and then I wouldn't need to do any actual checkins for those changes. If we can do that then the only thing I would need to change by hand would be the intl text that is in the MAINTAINERS file. Who maintains this automatic merge process? The man to ask about this is DJ Delorie. I'm not sure how much work it is on his part, though. Either way it would probably be best to do the initial sync by hand. And is it really plausible that nothing in src would need updating for the new intl? -- Daniel Jacobowitz CodeSourcery
Re: intl directory: gcc vs. src
On Tue, May 16, 2006 at 04:06:29PM -0700, Steve Ellcey wrote: I'm sure something might need updating after this change and I am willing to try and fix anything I break, but I am not sure what other testing I can do with the platforms I have available. Do you have any suggestions as to what products or platforms might cause problems? No; I'm just surprised that it worked. -- Daniel Jacobowitz CodeSourcery
Re: GCC-4.1 -fno-function-cse still supported?
On Fri, May 12, 2006 at 08:40:07PM +0200, Etienne Lorrain wrote: But when I tried (replacing in Gujin some calll by lcallw based on which function is called) it did not work as I expected it. For instance, -fno-function-cse seem ignored here: What are you expecting to happen here? The description said calls a constant function. This: int (*fct) (int i); is of course a function pointer. -- Daniel Jacobowitz CodeSourcery
Re: mthumb: generate a tail-call
On Wed, May 10, 2006 at 02:38:30PM -0600, Shaun Jackman wrote: What optimisation option is needed to prod arm-elf-gcc -mthumb to generate a tail call? ARM works as expected. It's not yet supported. Remember, bl has a long range but clobbers lr, and there's no long branch instruction, so you have to convert the call to indirect. It's probably a space loss, stack usage improvement, and I'm not sure offhand about performance - may be a bit slower. -- Daniel Jacobowitz CodeSourcery
Re: Summer of Code project discussion
On Sun, May 07, 2006 at 10:26:20PM +0200, Laurynas Biveinis wrote: - Cygwin's mmap() is still buggy. There was a lot of work on it previously, the last message I could find on the subject was http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00521.html . It suggested, that Cygwin's mmap() maybe could be un-blacklisted now. Well, it cannot. Zone collector unearths the problem that munmap(address, some_amount) actually unmaps 64KB when some_amount is e.g. 20KB. I've tested both MMAP_ANON and /dev/zero. If anybody is interested, I can provide the testcases. If nobody is, then maybe someday I'll find time to make testcases directly against Cygwin libc. For GCC it means that any mmap'y collector, if it's to become a single GCC collector, will need additional work here. It is possible to implement a workaround (free only 64KB worth of adjacent free pages) at cost of some memory expense, or use valloc(), or the malloc() code from ggc-page. Of course, only the first option is viable for copying collector. I wonder if cygwin's mprotect() has a set of similar issues. Or just use 64K pages on Cygwin. It sounds like that's what's going on. We may be fetching the page size incorrectly from the system. In fact, see how bogus the code currently in ggc-zone.c is for the page size? I suspect Cygwin is blameless here. The runtime page size detection would probably work better (but it's slower). - In other news, I've linked Boehm's GC with GGC, provided implementations for ggc_alloc_stat(), ggc_collect(), and stubbed out everything else. The result works only with disabled collection (i.e. Boehm's GC allocation routines and nothing else is used). Otherwise it collects identifier symbol table almost immediatelly after its creation. A little bit of debugging suggests that there is an issue of Boehm's GC being not aware of all roots. This can be solved either moving data structures living partly in malloc() memory, partly in GC memory to one of them or by registering additional roots with GC. Presumably you'd have to register all the GTY()'d roots... I don't know how that would work out. -- Daniel Jacobowitz CodeSourcery
Re: SoC application draft (Re: Summer of Code project discussion)
On Mon, May 08, 2006 at 02:52:46AM +0200, Laurynas Biveinis wrote: Now I'm off to write proposal for Google. Application draft can be found at http://www.cs.aau.dk/~lauras/application.txt I haven't submitted it yet, so I can incorporate some corrections, if you have any comments. It seems fine to me. One note for copying collection; I don't know that you need to solve the local variables problem. What I did during development was support both copying and non-copying collection; there's at least one suitable point (probably more - I did not look very hard) for copying. -- Daniel Jacobowitz CodeSourcery
Re: Dynamically generated code and DWARF exception handling
On Wed, May 03, 2006 at 07:12:43AM -0500, Perry Smith wrote: On May 2, 2006, at 9:21 PM, Mike Stump wrote: On May 2, 2006, at 4:23 AM, jacob navia wrote: To get to the corresponding catch, the runtime should skip through the intermediate frames in assembler generated by the JIT. We would like to know how should be the interface with gcc to do this. The C++ abi spec and dwarf specs are good background reading materials. I looked for those a while back and never found them. Does anyone have pointers to these? I'm not sure how... The first google result for C++ ABI is the Itanium C++ ABI working pages, which indeed describe the ABI that GCC 3.0 and later use: www.codesourcery.com/cxx-abi/ The first google result for DWARF standard is the home page of the DWARF working group, which includes the version 2 and version 3 standards: dwarf.freestandards.org/ -- Daniel Jacobowitz CodeSourcery
Re: Dynamically generated code and DWARF exception handling
On Wed, May 03, 2006 at 10:36:33AM +0200, jacob navia wrote: Maybe there is some references somewhere about this? Which JIT? Is there a source code example or something? I'm only familiar with proprietary JITs. Would sljl exceptions work? This has already been answered. Basically, no. -- Daniel Jacobowitz CodeSourcery
Re: Summer of Code project discussion
On Tue, May 02, 2006 at 09:34:38PM -0400, Daniel Berlin wrote: My thoughts are along the lines of Daniel's. I originally believed that the better data layout of lifetime and object specific pools would help, but it only helps about 10% in the extreme. Oh, one of the more interesting results from my testing: it can sometimes help much more than that - in precompiled header layout. Depending on the phase of the moon, I saw PCH performance improvements from 3% to 20%. -- Daniel Jacobowitz CodeSourcery
Re: Summer of Code project discussion
On Wed, May 03, 2006 at 11:31:00AM -0400, Daniel Berlin wrote: Again, I'm not sure the portability fixes are a real issue. There is nothing that prevents ggc-zone from being the default on systems with mmap, and ggc-page the default elsewhere. One of the reasons that the portability patches were rejected is that if we want to make ggc-zone copying/generational, any barrier style way of doing so will probably involve mprotect. I've not seen a system that supports mprotect but not mmap. In addition, if it was decided that in order to make ggc-zone the default, it would have to support non-mmap systems, i would accept the portability patches. Yes; I think that the zone collector as it is today (my fixes to it postdate that patch rejection) makes the idea of removing ggc-page more attractive than it was then. I think that with a reasonable amount of testing and tuning on different host systems, it might be reasonable to use it as the default - even if generational collection is disabled by the lack of mmap. -- Daniel Jacobowitz CodeSourcery
Re: Summer of Code project discussion
On Tue, May 02, 2006 at 09:07:19PM +0200, Laurynas Biveinis wrote: Having that in mind, also because I actually like doing infrastructural projects, cleaning up, speeding up things instead of implementing new features, I think I have found a suitable area for my project: garbage collection. I was looking for a compiler speed-up project yet avoid sinking into tree/RTL internals, as I doubt I would learn them effectively in time. Hi Laurynas, I wrote a lot of the current zone collector. Before that, Daniel Berlin did a lot of work on it. I really don't think I have time to mentor an SoC project (Daniel, do you, maybe?), but I'd be glad to talk to you about possible plans. - Investigate possibility of Boehm GC usage for compiler proper. Project page mentions inconclusive previous results here. I tried to google them in mailing list archives to no avail. Could somebody provide pointers to the previous investigation? I don't know of any offhand (which doesn't mean there isn't any). - Assuming that Boehm GC turns out to be unusable for the compiler, finish the zone collector. Again, searching mailing list about what's unfinished was not very fruitful. What's there works. I don't remember if it is sufficiently portable to e.g. systems without mmap to use as the default; and it needs some performance tuning still, probably, although I did a lot. - Assuming zone collector is done well before deadline, tune the collector by creating special zones for data with special lifetime. This turned out not to make a huge amount of difference; the problem is that the lifetimes of things are unclear in GCC and often long. I wrote a collector which could separate out data only referenced by a single function into its own zones; less than 30% of all data in a GCC run is specific to a function, because things like types and constants are not. I think it was even less. I don't have the statistics handy. The copying part of the collector worked well. The partitioning was less useful. My plan was to eventually enable generational GC; i.e. to be able to collect more frequently and assert that data for other functions had not changed since the last collection, since we optimize one function at a time. You could even mprotect the other zones read-only under --enable-checking to verify that we didn't clobber other functions. The problem was that the global zone was so large that collection time was still high. On March 13th 2005 I posted the copying collector to gcc-patches; you can find it in the archives. That was good for a performance boost by itself of a few percent, but used a lot of RAM; something cleverer might be doable that would use less RAM; I don't really know. I don't think I ever posted the automatic partitioning code; that computer is off right now, but I can dig out the code if you want to see it. -- Daniel Jacobowitz CodeSourcery
Re: Dynamically generated code and DWARF exception handling
On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote: Otherwise, would it be possible to generate the DWARF Tables and add those tables dynamically to the running program? Yes (could require OS changes). Under windows, Microsoft provides an API for JITs that does exactly that. Is there an equivalent API for linux? Don't think so. There isn't really. But I know that other JITs have managed to do this - I just don't know how. They may use a nasty hack somewhere. -- Daniel Jacobowitz CodeSourcery
Re: ARM gcc 4.1 optimization bug.
On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: Hi, I am using gcc4.1 for ARM to build Linux kernel. But there is a bug related to the gcc optimization. I assume this is correct mail list to report this bug. If not, please let me know. No, if you have a bug report, please use the bug reporting system. Please see: http://gcc.gnu.org/bugs.html -- Daniel Jacobowitz CodeSourcery
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 08:36:50PM -0400, DJ Delorie wrote: Well, that sounds like an autoconf bug. If it refuses to work when presented with a pile of compiler options, that just sounds bad. No, I think it's our bug - we do this: GCC_NO_EXECUTABLES GLIBCXX_ENABLE_SYMVERS([yes]) You can't logically expect that to work, no matter how many compiler options we give it - we've told autoconf to not produce any executables, then asked it to test something that requires them. Incorrect. Take a look at the implementation of GCC_NO_EXECUTABLES, please: AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes]) It sets gcc_no_link based on a link test. If the link test succeeds, then future link tests are allowed. If the link test fails, then future link tests are a fatal error (instead of just reporting the feature being tested for as missing). So if you really have enough to link, then it ought to work fine. What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch of link tests. Newlib is special because we arrange to build libstdc++-v3 before building newlib. That we require the configure option is somewhat lame. -- Daniel Jacobowitz CodeSourcery
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote: What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch The toplevel configure automatically adds that in a combined tree (or at least it should), if newlib is being built. Can you verify that this really happened? I know I've had to specify it manually recently. The two targets I'm currently working with are m32c-elf and sh-elf. For m32c-elf I added the -I/-L options, thinking it was unique. When sh-elf did similar things I realized otherwise. I'm currently working through a canadian and discovering other problems. We really need to test these things more often :-P Frankly, people who are interested in using the combined tree build process need to test it - just like you're doing. There's just too many possible configurations. -- Daniel Jacobowitz CodeSourcery
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote: $SYSTEM_HEADER_DIR is supposed to be /mingw/include for a native MinGW target (and since host == target, the build is being considered native). However, in a crossed- native build, I cannot have MinGW headers in this path, so the way I work around this problem is to additionally specify --with-sysroot=$PREFIX and extract MinGW headers into $PREFIX/mingw. This lets the build and installation complete successfully, but when I tar this installation and install it on a Windows machine, GCC fails to find the system headers. The workaround *then* is to rename the mingw folder to $TARGET (i.e. i686-pc-mingw32) again. Needless to say, this is painful. In earlier releases, I used to be able to just extract the headers to $PREFIX/$TARGET, do the crossed-native build, install the compiler and then bundle this installation up to create a relocatable toolchain. This was the whole point of the article: If you look at HEAD, you'll find a new --with-build-sysroot option. Does that help? We added it for some very similar configurations... -- Daniel Jacobowitz CodeSourcery
Re: Idioms for byteswapping and unaligned memory access
On Thu, Apr 20, 2006 at 08:38:00AM -0700, H. J. Lu wrote: On Thu, Apr 20, 2006 at 05:18:08PM +0200, Olivier Galibert wrote: I need to be able to do unaligned memory accesses to memory in big-endian or little-endian mode. For portability, I'd like to do it in pure C, but I'd like the compiler to generate optimal sequences for the operations. Most CPUs that I know of even have special instructions designed to speed up part or all of these operations. So I'm looking for ways of writing these to-be-inlined elemental functions in C that gcc will recognize as such, while still working correctly, if more slowly, for other compilers. bfd does that. Have you looked at the code generated for these? I was able to drastically improve performance of a project I was working on, on x86, by forcing BFD to do unaligned loads instead of bytewise loads, but I never found a clean way to do it automatically. -- Daniel Jacobowitz CodeSourcery
Re: optimizing away parts of macros?
On Mon, Apr 17, 2006 at 04:42:18PM -0500, David Nicol wrote: GCC appears to be treating my long macro as some kind of block and throwing out variables that are not used within it instead of simply pasting the code in at the macro invocation point. Is this a known problem with 4.0.2? Is there a workaround? Should I upgrade? This is not a useful bug report, sorry. Please take a look at the bug reporting instructions on gcc.gnu.org. -- Daniel Jacobowitz CodeSourcery
Re: Toolchain relocation
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote: I had a look through gcc.c and noticed that standard_exec_prefix and standard_libexec_prefix are constants which refer to the configured install path. gcc_exec_prefix and gcc_libexec_prefix are the equivalent paths adjusted for the relocated toolchain but the unadjusted variables are used in several places. The attached patch switches them for the adjusted variables and is a partial fix for my problem but unfortunately isn't the whole story. The relocated compiler is still checking for includes in the configured location but all the directories reported from -print-search-dirs are now relocated. No, this patch is not correct. Take a wander through set_std_prefix and the call to update_path in add_prefix. You might want to play around with relocation on a non-MinGW-hosted system, for comparison. Does that work better? If so, it's likely something which does not handle drive letters. make_relative_prefix may need to be taught something about them. -- Daniel Jacobowitz CodeSourcery
Re: Toolchain relocation
On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote: Hi, I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. How did you configure the toolchain? Which was the configured install directory and which was the relocated install directory? -- Daniel Jacobowitz CodeSourcery
Re: Updating a ssh key
On Mon, Apr 10, 2006 at 08:47:26PM -0700, Steve Kargl wrote: What is the procedure for updating my public key on gcc.gnu.org? Note, I long ago forgot the passwd (if I even had one) for my account, so using scp is out of the question because I no longer have ssh access (for some reason). To make a long story short, my hard drive decided to scramble itself beyond repair. After installing a new hard drive, re-installing the OS, and grabbing my gcc hacking account off of backup tape, I can no longer access the repository? Easy: ask overseers@ to install a new key for you. -- Daniel Jacobowitz CodeSourcery
Re: Update of mirrors web page
On Sat, Apr 08, 2006 at 05:02:28PM +0200, Martin Michlmayr wrote: * Gerald Pfeifer [EMAIL PROTECTED] [2006-04-08 16:15]: ftp://core.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird structure) ftp://ftp.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird structure) (When you refer to weird structure, is this about gcc3.3 residing in an extra subdirectory called releases?) Most mirros on that page have a nicely structured hierarchy with several sub-directories (infrastructure, libstd++, etc). Those with a weird structure have a sub-dir for every release, and are missing some of the other dirs (e.g. infrastructure). That means they mirror from ftp.gnu.org, rather than gcc.gnu.org. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
On Mon, Apr 03, 2006 at 11:21:35PM +1200, Nick Roberts wrote: I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the program below I get results which didn't occur before (Fedora Core 3). I posted them to [EMAIL PROTECTED] but I think something is up with GCC 4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These results are with DWARF 2. GCC 4.1.0 with stabs worked as expected They've been optimized away. Not surprising, since they are unused, although slightly surprising that it happened with -O0. On x86, where they're on the stack on entry, we could probably have done better even with optimization. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
On Tue, Apr 04, 2006 at 09:05:28AM +1200, Nick Roberts wrote: It also causes GDB to generate errors on the output of other commands: (gdb) info locals argc = Cannot access memory at address 0x0 as well as the GDB/MI equivalent -stack-list-locals. This breaks the front end that I'm writing fo Emacs. That's a bug in GDB, and not hard to fix. You're welcome to do it, or to file it in GNATS :-) I'm sure that GDB can be rewritten to overcome this but what other optimizations do/will GCC developers decide users must have? The above optimization seems just to save a few bytes unless a program is deeply nested. Why not reserve it for -O1 and higher? This is not how compiler optimization works. It is probably an accident resulting from the compiler's internal representation. You may want to file it in the GCC bug tracking system, if there is not already an equivalent bug. -- Daniel Jacobowitz CodeSourcery
Re: R_PPC_REL24 overflow
On Wed, Mar 29, 2006 at 01:53:31PM -0500, James Lemke wrote: The generated asm makes the reference as: bl [EMAIL PROTECTED] # 141 *call_value_nonlocal_sysv/1 [length = 4] And for this, gas generates: R_PPC_REL24 __pthread_mutex_lock Can anyone help clarify what is / should be going on here? All fine so far. Then, ld should resolve the branch to point to a PLT entry - you want to figure out why that isn't happening and the branch is being output into the shared library. -- Daniel Jacobowitz CodeSourcery
Re: failed gcc-4.0.3-1(Debian) bootstrap with ARM VFP and binutils-2.16.1cvs20060117-1
On Fri, Mar 24, 2006 at 12:01:26PM +0100, [EMAIL PROTECTED] wrote: ld: *_s.o uses VFP instructions, whereas ./libgcc_s.so.1.tmp does not (Complete log in attachment). I found this message quite strange, as libgcc_s.so.1.tmp was the output of the linker, so it should have been created with the same modes as the objects it should contain. It means that some earlier file in the link set the mode of libgcc_s.so.1, and that file did not use VFP. You might want to check the other files included in the linker invocation. Moreover, --msoft-float and --mfpu=vfp were explicitly passed to xgcc. However, looking at the log I see that collect2 does not get --msoft-float and --mfpu options. Could this be a problem? I tried to modify build/gcc/specs, to no avail... No, this is not an issue. Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/arm-vfp-linux-gnu/include/c++/4.0.3 --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --with-float=soft --with-fpu=vfp --enable-checking=release --program-prefix=arm-vfp-linux-gnu- --includedir=/usr/arm-vfp-linux-gnu/include --build=i486-linux-gnu --host=i486-linux-gnu --target=arm-vfp-linux-gnu /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/collect2 --eh-frame-hdr -shared -dynamic-linker /lib/ld-linux.so.2 -X -m armelf_linux -p -o ./libgcc_s.so.1.tmp /usr/arm-vfp-linux-gnu/lib/crti.o /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtbeginS.o -L/usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc -L/usr/arm-vfp-linux-gnu/bin -L/usr/arm-vfp-linux-gnu/lib -L/usr/lib/gcc/../../arm-vfp-linux-gnu/lib --soname=libgcc_s.so.1 --version-script=libgcc/./libgcc.map -O1 libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o libgcc/./_umodsi3_s.o libgcc/./_modsi3_s.o libgcc/./_dvmd_lnx_s.o libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtendS.o /usr/arm-vfp-linux-gnu/lib/crtn.o /usr/arm-vfp-linux-gnu/bin/ld: ERROR: /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtbeginS.o uses VFP instructions, whereas ./libgcc_s.so.1.tmp does not Looks like you're using an installed crti.o. I bet that's not built with VFP. You might want to look into e.g. crosstool; it knows how to bootstrap a toolchain with particular options. -- Daniel Jacobowitz CodeSourcery
Re: Core dump in application on SuSE9 zLinux
On Thu, Mar 23, 2006 at 10:02:22AM +0530, harshpreet_singh wrote: Can anyone please help me resolve the issue? On facet it seems to be a C Library issue. Please suggest all the possible solutions. I fail to understand why an application which is working fine on SuSe8 zLinux (SP3) is failing on SuSE9 zLinux (SP2). Whatever it is, it's probably not a GCC issue; this is not the appropriate list to ask questions about multithreading. -- Daniel Jacobowitz CodeSourcery
Re: GCC libtool - plans for moving to libtool 1.5?
On Fri, Mar 17, 2006 at 02:59:26PM -0800, Steve Ellcey wrote: I was wondering if there are any plans to move the libtool that is in the GCC tree to 1.5? The current libtool in GCC appears to be based on the 1.4 version and the real libtool project is currently shipping libtool 1.5.22. This is still blocked on the move to a newer autoconf in all subdirectories. Or, on someone figuring out whether we can migrate some subdirectories to a newer libtool without breaking others. -- Daniel Jacobowitz CodeSourcery
Re: autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/fixincludes/inclhack.def
On Sat, Mar 11, 2006 at 11:30:45AM -0800, Mike Stump wrote: Hum, I'd say that contrib/gcc_update should be used, if it wasn't, and that the make files should only have the dependencies if in maintainer mode, and that maintainers should have autogen. Toon would have to give us a hint which part failed him, for me to know just what went wrong. It's not a generated file. Autogen is run during the fixincludes testsuite. -- Daniel Jacobowitz CodeSourcery
Re: g++ 4.1.0/4.2.x, x86/x86-64, segfaults due to bogus SSE alignments
On Sat, Mar 11, 2006 at 03:43:45AM +0100, tbp wrote: I haven't made a bugreport yet, as that would require disclosing large amounts of code, but i'd like to know if it's a known issue by any chance. Unlikely, since you haven't described at all what the problem is. That's why we prefer bug reports with testcases. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote: I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor string is picked up by my ebuild scripts to pass the iwmmxt target flags. Given my objective, am I wrong to try to make a tool chain that targets xscale-iwmmxt-linux-gnueabi specifically or do you just consider it unnecessary effort? I don't think there's any point to the xscale-* triplets nowadays. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote: On 3/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. The problem has nothing to do with warnings from tar, which are neither errors nor silent failures. I believe a file either got skipped or unpacked with the wrong name. Egads. Can you point me to more info? I've been building with older versions of tar without any problem beyond the warnings. I don't know where the report was. I think it was on this list in the last week or two. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote: OK, thank-you. I'll target arm-iwmmxt-linux-gnueabi with --with-cpu= etc and --disable-multilib. The vendor string is for my build scripts and also will help differentiate the toolchain, is that valid? Yep. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
On Thu, Mar 02, 2006 at 12:27:46AM +, Steven Newbury wrote: I've given this a go. I've successully built a stage1 cross compiler and installed the glibc headers. However, on re-building gcc it fails to link libgcc: ... ./libgcc_s.so.1.backup; else true; fi mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 ln -s libgcc_s.so.1 ./libgcc_s.so /usr/arm-iwmmxt-linux-gnueabi/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 Any hints? Please either take this to the crossgcc list or look at how crosstool works. This is a FAQ for building Linux cross-compilers. -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote: Here's a great example from uintp.adb (which is the cause of the testsuite hang FWIW) We have a loop with the following termination code in uintp.num_bits # BLOCK 8 # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs_back,exec) # num_2 = PHI num_49(5), num_10(6); # bits_1 = PHI bits_50(5), bits_13(6); L7:; num.265_5 = (types__TintB) num_2; if (num.265_5 = 0) goto L5; else goto L4; # SUCC: 7 (true,exec) 6 (false,exec) ... So, why am I bringing this up? Because num can actually have the value 0x8000 at runtime, which is out of its type's MIN/MAX range. And what do you think happens? Well, given the (valid) simplification of the loop test and the way num is assigned within the loop (num = num / 2), the loop never terminates. I've been following this entire thread, and I think there's a serious disconnect between the parties - it's unfortunate that none of the tree-ssa folks involved know Ada as I suspect that would straighten it out in a hurry. This is a perfect example. Now that we have some concrete code that's causing a problem, let's take a look at it (bear in mind, I don't know Ada either): function Num_Bits (Input : Uint) return Nat is Bits : Nat; Num : Nat; begin if UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0; else Bits := Base_Bits * (Uints.Table (Input).Length - 1); Num := abs (Udigits.Table (Uints.Table (Input).Loc)); end if; while Types. (Num, 0) loop Num := Num / 2; Bits := Bits + 1; end loop; return Bits; end Num_Bits; I'm going to assume that UI_Is_In_Int_Range isn't true for 0x8000. The other case is still assigning 0x8000 to Nat somehow. I'd be amazed if that's really valid Ada! Could someone who knows the language comment, please? I wouldn't have a problem with non-canonical bounds if there were no way to get a value into an object which is outside the bounds. But if we can get values into the object which are outside those bounds, then either the bounds are incorrect or the program is invalid. Ignoring 'Valid, which folks agreed to do earlier, I think everyone agrees with this statement - which is why I suspect that there's something wrong with Num_Bits. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 04:27:48AM +, Steven Newbury wrote: Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm using the target xscale-iwmmxt-linux-gnueabi, I've added support for this target to binutils and built a cross linker etc. I've proceeded to add a suitable target in config.gcc which supports EABI, xscale and Linux basing it on the existing arm/linux target and replacing the linux-elf.h file with a modified one based on xscale-elf.h which I've called xscale-linux-elf.h. I then attempted to build a stage1 compiler with --with-abi=iwmmxt --with-cpu=iwmmxt --with-arch=iwmmxt, but as soon as the build tries to run xgcc I get the error below. It looks like it's getting the types wrong, but I'm very new to GCC internals and I'm not sure where to look. Try just using arm-none-linux-gnueabi and --with-cpu=iwmmxt --with-arch=iwmmxt; you almost certainly do not want --with-abi=iwmmxt. The error you gave suggests that you didn't modify something properly to handle the xscale-linux-gnueabi target, but arm would work just fine. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: Thanks for the quick response! I'm sure it seems I like to make hard wok for myself! It gets worse, I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm not concerned about being able to run old binaries. So is using abi=iwmmxt really not what I want? A really bad idea? Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. -- Daniel Jacobowitz CodeSourcery
Re: can't create crtbegin.o: Invalid bfd target
On Mon, Feb 27, 2006 at 10:20:43AM +0800, Eric Fisher wrote: Are there anyone can give me some suggestion? The configuration of gcc is, ../gcc-3.4.4-mytarget/configure --target=mytarget-lin ux --prefix=/home/smj/local/ --with-as=/home/smj/local/bin/mytarget-linux-as --with- ld=/home/smj/local/bin/mytarget-linux-ld Then this is the wrong list; your binutils port is broken. -- Daniel Jacobowitz CodeSourcery
Re: question about pic and relocation
On Thu, Feb 23, 2006 at 01:51:08PM +0800, Eric Fisher wrote: But flag '-shared' and '-fpic' are used to create shared object, aren't they? When I use objdump to see the codes, I find that the program address doesn't start from 0. Such as, On MIPS, it happens that shared libraries are linked as 0x5ffe or thereabouts. It's historical. Why? And the symble 'b' is of absolute type(*A*)? I don't know; not enough information. -- Daniel Jacobowitz CodeSourcery
Re: question about pic and relocation
On Thu, Feb 23, 2006 at 01:33:05PM +0800, Eric Fisher wrote: $ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps We can see this below from fun.s, lw $2,%gp_rel(b)($28) I think symble 'b' should be of GOT relocation. But it isn't. $ mips-elf-readelf -r fun.so There are no GOT relocations in shared libraries. They're resolved by the linker. I have no idea about the error and the symble 'b' of pic codes. Yet, when use this below $ mips-elf-as fun.s -call_shared -o fun.so $ mips-elf-readelf -r fun.so That's not a shared object, no matter what you call it. You have to assemble and then link; please let GCC do the linking, it knows how to invoke the linker properly for each platform. -- Daniel Jacobowitz CodeSourcery
Re: Toplevel bootstrap patches cause bootstrap breakage
On Tue, Feb 21, 2006 at 01:15:47PM -0500, David Edelsohn wrote: The latest toplevel bootstrap patches have broken bootstrap on AIX. Executables are being re-linked when installed in prev-gcc. In stage2, it relinks with the system gcc, which works, but in stage3 it relinks with prev-gcc/xgcc which does not exist because the bootstrap is in the process of installing it. I'm not quite sure what you mean by installing in prev-gcc; could you show me the tail end of a log? -- Daniel Jacobowitz CodeSourcery
Re: Toplevel bootstrap patches cause bootstrap breakage
On Tue, Feb 21, 2006 at 02:16:27PM -0500, Daniel Jacobowitz wrote:
On Tue, Feb 21, 2006 at 01:50:47PM -0500, David Edelsohn wrote:
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc \
make install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
That's the problem.
Paolo, we can't run make targets inside prev-gcc. install-headers-tar
has dependencies; one of them must go all the way back to xgcc (not
surprising), and moving gcc and prev-gcc around means that xgcc
will need to be rebuilt, probably because it is now older than the
headers in prev-gcc.
I think that either we need a variant of install-headers-tar with no
dependencies to do this, or find some other way entirely.
Want to try this?
--
Daniel Jacobowitz
CodeSourcery
Index: Makefile.in
===
--- Makefile.in (revision 111338)
+++ Makefile.in (working copy)
@@ -3195,7 +3195,7 @@
-chmod a+rx include
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc \
- $(MAKE) $(INSTALL_HEADERS_DIR) DESTDIR=`pwd`/../gcc/ \
+ $(MAKE) real-$(INSTALL_HEADERS_DIR) DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
(TARGET_MACHINE='$(target)'; srcdir=`cd $(srcdir); ${PWD_COMMAND}`; \
@@ -3789,6 +3789,18 @@
install-headers-cp: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir
cp -p -r include $(DESTDIR)$(libsubdir)
+# Targets without dependencies, for use in prev-gcc during bootstrap.
+real-install-headers-tar:
+ (cd `${PWD_COMMAND}`/include ; \
+tar -cf - .; exit 0) | (cd $(DESTDIR)$(libsubdir)/include; tar xpf - )
+
+real-install-headers-cpio:
+ cd `${PWD_COMMAND}`/include ; \
+ find . -print | cpio -pdum $(DESTDIR)$(libsubdir)/include
+
+real-install-headers-cp:
+ cp -p -r include $(DESTDIR)$(libsubdir)
+
# Install supporting files for fixincludes to be run later.
install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-itoolsdirs \
macro_list xlimits.h
Re: software floating point host triplet?
On Mon, Feb 20, 2006 at 06:54:07PM +0100, Simon Richter wrote: Hello, I have the interesting and somewhat taunting task of providing a toolchain that assumes -msoft-float unless told otherwise. Obviously, this can be arranged with appropriate changes to the specs, however I'd like to integrate this in a way that would benefit everybody. Have you tried --with-float=soft, which works on several different architectures already? -- Daniel Jacobowitz CodeSourcery
Re: gcc and attribute __packed__
On Fri, Feb 10, 2006 at 04:56:20PM +0100, Nicolas DICHTEL wrote:
Hi all,
here is the result on ARM of my little program:
[EMAIL PROTECTED]:/usr/admin# ./test2
4 5 6 8
2 3 4 6
Is it normal to add an attribute __packed__ on each union{}
contained in a structure, or is it a bug of my compiler ?
On X86, this kind of structure has always the good size.
As Andrew alluded to, this is a quirk of the ARM APCS (arm-linux's
ABI). It's changed in the newer ARM AAPCS (arm-linux-gnueabi).
union u {
u_int8_t a[2];
u_int16_t b;
};
The size of this type is four on that ABI. It doesn't matter if you
pack a structure containing this; that eliminates padding in the
structure, but doesn't change the type or size of the union.
--
Daniel Jacobowitz
CodeSourcery
Re: How to create libgcc_eh.a for mips-elf-gcc?
On Fri, Feb 10, 2006 at 11:01:10AM +0800, Eric Fisher wrote: Hi, I will be appreciated for anyone tell me how to create libgcc_eh.a for mips-elf-gcc. I used this configuration, but failed ../gcc-3.4.4/configure --target=mips-elf --enable-languages=c --enable-shared Yet libgcc_eh.a can be created for local i686 gcc, when use this, ../gcc-3.4.4/configure --enable-languages=c --enable-shared Actually, I ask this question, because glibc requires libgcc_eh.a during compilation. You may want to take a look at crosstool, which knows a lot about how to build glibc. For one thing, you can't do it with a mips-elf targeted compiler; glibc builds for mips-linux, not for mips-elf. -- Daniel Jacobowitz CodeSourcery
Re: Reconsidering gcjx
On Fri, Jan 27, 2006 at 11:59:06AM -0700, Tom Tromey wrote: Column numbers, as Per mentioned, are trickier. We know that ecj has this information (since Eclipse itself uses it), but there is no standard way to pass it via the class file format. But does gdb actually use column numbers? Not today, no. -- Daniel Jacobowitz CodeSourcery
Re: bld/gcc/testsuite disappears when recompiling
On Wed, Jan 25, 2006 at 09:06:06AM -0500, Diego Novillo wrote: Paolo Bonzini wrote: I suppose. I don't understand why can't you just look in stage3-gcc/testsuite, but I guess you know what you're doing. :-) Hmm, now that I think about it again. The log contains command lines that use the compiler built in bld/gcc. Something like bld/gcc/testsuite/gfortran/../../gfortran, right? If I had to rebuild the stage1 binaries inside bld/stage1-gcc, it seems to me that I won't be able to cut and paste from gfortran.log anymore. I will have to modify all the paths to bld/stage1-gcc? If you run all-stage1, or stage1-start, then the top level will put the stage1 gcc directory back into place. There's a separate gcc subdirectory for every stage; the current stage will be named gcc, and all the others will be named stageFOO-gcc. -- Daniel Jacobowitz CodeSourcery
Re: [CFARM] Automatic bootstrap check of each svn commit on the GCC Compile Farm
On Mon, Jan 23, 2006 at 01:27:50PM +0100, Richard Guenther wrote: Is sending each rev testresults to gcc-testresults ok? Yes, I think that is useful. Well, a nice optimization for people using the list archives would be to only send test logs that have changed since the last one posted. Optionally, by some change other than the total number of PASS. -- Daniel Jacobowitz CodeSourcery
Re: branch_target_register_class - receipt for a crash
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int (* branch_target_register_class) (void);
The only place where this is referenced is in gcc/bt-load.c
and in esp the global branch_target_load_optimize() function.
Right away at the start. However there is no initialization of
brnach_target_register_class at all anywhere.
This of course will let the compiler crash on *every* call
to branch_target_load_optimize().
If this were true, it would have been very easy to check: pass the
option, watch the compiler crash. Did you try it?
- It's not in struct sched, which is not in struct asm_out.
- If you'd loaded up the compiler in GDB you'd probably have
seen it initialized to hook_int_void_no_regs.
- This comes from TARGET_BRANCH_TARGET_REGISTER_CLASS.
- SH redefines that to sh_target_reg_class.
--
Daniel Jacobowitz
CodeSourcery
Re: Example of debugging GCC with toplevel bootstrap
On Wed, Jan 18, 2006 at 08:36:13AM -0500, Richard Kenner wrote: MRS and Eric Botcazou objected strongly against not being able to build a 1-stage GCC with --disable-bootstrap. And that's never going to happen. One would hope that wouldn't, but what I heard was an objection against removing what's there now, namely the capability to bootstrap GCC and *just* GCC. In other words, to have a mode when you can do a bootstrap that does no more work than the present one does. I don't believe anyone has said that except for you. Perhaps Mike can clarify if that's what he meant. -- Daniel Jacobowitz CodeSourcery
Re: Excluding C++ Library Code
On Wed, Jan 18, 2006 at 07:25:58PM -0800, Mike Stump wrote: On Jan 18, 2006, at 12:22 PM, Eric Lemings wrote: Right now the infrastructure for it isn't there, but someday it will be. But how would you indicate to the debugger what constituted uninteresting headers? I figure the responsibility for this would probably reside more with the compiler than the debugger (e.g. -gnostdinc++) but I as hoping it could be done already. Either, we can mark the debug information with `system header', or gdb can strncmp (/usr/include) and a few others... :-) gcc has a slightly easier time know when a header is a system header, but a project GUI has a easier time having check boxes for components you want to stop in and which ones you don't want to stop in, with system headers being just one of the boxes. Right - my point was only that I've thought about it long enough to know it needed some more thinking about :-) I definitely agree that the debugger should be doing it, not the compiler. It's not appreciably harder here and it makes more sense to allow the user to just toggle a switch to suddenly step into libstdc++. -- Daniel Jacobowitz CodeSourcery
-Wpointer-sign for GCC 4.1
Someone's informed Richard Stallman that this (annoying) warning will not be enabled by default in GCC 4.1. But, it currently seems to be. Should it be turned off before the release? If not, who told RMS it was? :-) -- Daniel Jacobowitz CodeSourcery
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, Jan 16, 2006 at 01:52:43PM +0100, Paolo Bonzini wrote: I can see how a compiler bug, that manifests as a miscompilation of the assembler, triggers a bootstrap failure if you also build the assembler three times, each time using the previous compiler *and* assembler. For the record, this is non-hypothetical. It happened to me a few weeks ago - if I'd been bootstrapping in a combined tree, stage1 gcc would have miscompiled stage2 as which would have misassembled stage2 gcc. -- Daniel Jacobowitz CodeSourcery
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, Jan 16, 2006 at 09:03:26AM -0500, Richard Kenner wrote: This *will* stop working, Then I'm confused: I thought the whole point of --disable-bootstrap is to keep the old mechanism instead of getting the new one. The point of --disable-bootstrap is to disable bootstrapping. The old mechanism _will be removed_. I've explained that on this list at least half a dozen times now - including directly to you. You will always have a bootstrap sequence and a non-bootstrap sequence, but you'll need to reconfigure to switch between the two. That's *wierd* to me. It's weird to me too. We've been investigating ways to make it unnecessary. In the old scheme, a bootstrap meant just rebuilding the compiler. There seems to be a belief that it would be good if it rebuilt more. So the way I thought things were going to be done, if you say make bootstrap with --disable-bootstrap, it does the old (shorter) method and if you say it with --enable-bootstrap, it does the new (longer). If this isn't what's implemented, why isn't it? The old mechanism puts control of the bootstrap in gcc/Makefile. The new mechanism puts control of the bootstrap in the toplevel Makefile. This is an important, fundamental difference. It means that we can bootstrap things that don't live in the gcc subdirectory. The most important of these is libgcc and the crt startup files, which currently do live in the gcc directory, and folks have wanted to move out of it for five or ten years. We can't skip them during a bootstrap; it just won't work. -- Daniel Jacobowitz CodeSourcery
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, Jan 16, 2006 at 09:24:29AM -0500, Richard Kenner wrote: The point of --disable-bootstrap is to disable bootstrapping. Why would somebody ever want to *disable* it? If you don't want to bootstrap, you just don't *do* it! Oh come on. This is semantics. --disable-bootstrap is the equivalent of not doing it. The most important of these is libgcc and the crt startup files, which currently do live in the gcc directory, and folks have wanted to move out of it for five or ten years. We can't skip them during a bootstrap; it just won't work. Why is it so important to move them out? It would seem to me that the bootstrap issue is a good reason *not* to! So we define the GCC directory as containing precisely those things that are *needed* for a bootstrap and those things outside are things that we might also *want* to bootstrap. It's important because: - People want to build libgcc at a separate time for the compiler. - The current build system has piles of cruft related to the fact that half of the GCC subdirectory is built using a different compiler than the other half. - The current layout is a mess and very hard to untangle from the compiler proper. I realize that none of these things are issues for you, personally. Part of playing in the same tree as everybody else is that you need to consider other people's concerns from time to time, though. We're listening to yours; please stop blowing off mine. -- Daniel Jacobowitz CodeSourcery
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, Jan 16, 2006 at 09:48:14AM -0500, Richard Kenner wrote: Why would somebody ever want to *disable* it? If you don't want to bootstrap, you just don't *do* it! Oh come on. This is semantics. --disable-bootstrap is the equivalent of not doing it. I don't follow. If I don't want to bootstrap, I won't say make bootstrap. Why do I need a configure option to *prevent* me from saying that? Because other rules in the toplevel makefile need to know whether they are being used as part of a bootstrap or not. I'm not going to respond to the rest. We're going around in circles and not making the slightest forward progress. -- Daniel Jacobowitz CodeSourcery
Re: Question about the internal compiler error in verify_local_live_at_start
On Fri, Jan 13, 2006 at 10:34:27AM +0800, Eric Fisher wrote: Hello, When I run the test suite for my port of gcc, there are some failures caused by the optimization flag such as -O2/-O3, and the messages are like, 930120-1.c: In function `f': 930120-1.c:138: internal compiler error: in verify_local_live_at_start, at flow. c:546 It seems that because of the regsets doesn't match after reload. But can you give me any clues? I think it's hard to check the bugs. This error usually means that something has gone wrong two or three passes before, but not been detected until now - e.g. a needed definition being deleted. -- Daniel Jacobowitz CodeSourcery
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, Jan 16, 2006 at 12:43:13PM -0500, Richard Kenner wrote: Only if you assume a cross compiler and a true native compiler generate different code. I certainly hope that isn't the case. Why not? It's a pretty strong statement to assume they generate *exactly* the same code under all circumstances and it seems unnecessary. All we require is that they both generate *correct* code. It's perfectly reasonable for the optimizers to behave slightly differently in host and cross configurations, such as in what they fold. Clearly, it's advantageous to minimize these differences, and we do that, but I think having to reduce them to zero is too strong a requirement, especially since it's so easy to avoid starting a bootstrap with a cross-compiler. As a heavy debugger of cross compilers I strongly disagree with this sentiment. Host dependencies of any sort are a bug. -- Daniel Jacobowitz CodeSourcery
Re: _Pragma3.c failure on gcc 4.1 branch for darwin 8.4.0
On Sun, Jan 15, 2006 at 12:25:51PM -0500, Jack Howarth wrote: Joseph, Thanks for the hint. Correcting the timestamps with... contrib/gcc_update --touch ...eliminated the failure in _Pragma.c. However I am still baffled as to why this was necessary since I was building from a clean svn pull of the gcc 4.1 branch using svn 1.3.0. Is svn that broken that I need to manually correct the timestamps after every pull? That this ever worked with CVS required a lot of luck. -- Daniel Jacobowitz CodeSourcery
Re: Cross compiling libstc++-v3 fails
On Wed, Jan 11, 2006 at 12:10:32PM +0100, Leif Ekblad wrote: In configure script, line 2580, there is a link test which checks if an executable can be generated. The config.log file emits the following errors: /usr/local/bin/rdos-ld: unrecognised emulation mode: -o Supported emulations: elf_i386 collect2: ld returned status 1 exit status. This error later in the configure scripts leads to an abort with Link tests are not allowed after GCC_NO_EXECUTABLES. To try to figure out this problem, I manully compiled the same file with the same options using the same compiler (xgcc), and it returns the same error. I then tried to use the cross-compiler built using gcc-4.1-20051008, with which I can build other executables, and it returns the same error. Only if I remove the -B/usr/src/toolchain/gcc-4.2-20060107/host-i686-pc-linux-gnu/gcc option, does it generate the executable without any errors. How can this include give ld the wrong emulation mode? Apparently, there is no -o in any file in the build-directory. Sounds like there's an error in your specs. Run gcc -v and see what it's invoking. -- Daniel Jacobowitz CodeSourcery
Re: Time to add new copyright years...
On Wed, Jan 04, 2006 at 04:41:11PM +, Joseph S. Myers wrote: On Mon, 2 Jan 2006, Paolo Bonzini wrote: Just to remember you all that before committing a patch, you now have to check if the copyright year includes 2006. And this includes the --version copyright year of any program your code forms part of, and the overall copyright notice dates of any manual you change (i.e. in general you may need to change dates in other files). Unless I am misreading the recent announcement on gnu-prog, in fact, we need to bump the copyright year on every file. Details in maintain.texi. (No, I don't really understand the reasoning. Feel free to follow up on gnu-prog-discuss if you are on that list.) -- Daniel Jacobowitz CodeSourcery
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: Actually, looking more closely, the libiberty.a is the only one installed that way (from the gcc sources). All others (for example libstdc++.a) seem to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? Bingo. :-) http://gcc.gnu.org/PR16513 I wonder how many more examples like that we need before we impose testing after install and not in tree... Only consequence for the few who configure with --prefix=/usr from their tree will be to change to --prefix=/some/user/dir so install doesn't break the system if the tested compiler is not up to the task. We can do this without touching --prefix, in fact, via DESTDIR and relocatable installs. It's just a bit disruptive to the workflow, so I wanted to wait until toplevel bootstrap was settled first. -- Daniel Jacobowitz CodeSourcery
Re: Testing GCC install (was: inconsistency in location of static and shared libraries on sparc64-sun-solaris*)
On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote: On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote: On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: Actually, looking more closely, the libiberty.a is the only one installed that way (from the gcc sources). All others (for example libstdc++.a) seem to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? Bingo. :-) http://gcc.gnu.org/PR16513 I wonder how many more examples like that we need before we impose testing after install and not in tree... Only consequence for the few who configure with --prefix=/usr from their tree will be to change to --prefix=/some/user/dir so install doesn't break the system if the tested compiler is not up to the task. We can do this without touching --prefix, in fact, via DESTDIR and relocatable installs. I assume DESTDIR will suffer a lot of recurrent breakage if we still test in tree when it goes in. It's just a bit disruptive to the workflow, so I wanted to wait until toplevel bootstrap was settled first. Yes, another impact of testing after install is that many small dev scripts will have to be changed to make check after make install and not before. No, you've missed my point. DESTDIR support (which we already have, and people use constantly) allows us to install a tree somewhere different than its configured --prefix. Relocatable toolchains (ditto) allow the toolchain to work when run from an address different than the configured --prefix. make check, or even make all, can finish with make install DESTDIR=$top_objdir/install. That will generate an installed toolchain which behaves just like the final installed toolchain. -- Daniel Jacobowitz CodeSourcery
Re: selection or target tools
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote: On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote: On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote: Hello! The new scheme to select target tools breaks building GCC for me. Maybe I have an unusal setup. The problem in my case is that configure now chooses tools from $prefix/bin. It did use tools from $prefix/$target/bin before. On my setup I have *different* tools in those places. Until know the tools from $prefix/$target/bin were selected and everything was fine. Now the build process creates eg. gcc/as which uses as from $prefix/bin. That assembler is *never* invoked when I running target-gcc. Thus I am surprised that configure now prefers that version. Is the current behaviour a bug? From your description I assume this is a native build ($target == $host). When did this change? Sorry for being vague, its a cross-compiler (build == host). The build errors out for libgcc.a since gcc/xgcc uses the wrong assembler. The last successful build was at the beginning of decemeber. Wait wait wait wait wait. This is a cross compiler. Are we mistakenly running $prefix/bin/$target-as, which is a bad version, or are we really running $prefix/bin/as, a program named as? If we're doing that, let's fix that separately - it's a nasty bug! Also, _why_ do you have different tools in those two places? Is this important? I kept binutil versions in $prefix/bin because at times its useful to have it, eg. comparing its output/behaviour. The replaced tools in $prefix/$target/bin are better suited for my needs, thus I installed them there and until recently GCC always used these tools. You see, normally the binutils make install hardlinks bin/mips-linux-as to mips-linux/bin/as. GCC probably has more than one assumption that they're compatible assemblers. -- Daniel Jacobowitz CodeSourcery, LLC
Re: asm label generation bug?
On Thu, Dec 22, 2005 at 02:28:08PM +0100, Piotr Wyderski wrote: HOST: AIX, 8 * IBM POWER2 CPU COMPILER: GCC 4.0.1, GCC 3.4.4 I am trying to compile my low-level library, which contains several inline assembly functions. It doesn't work, because the compiler (4.0.1) does not replace local labels from the assembly code (i.e. 0:, 1:, etc.) with their machine-specific replacements (LCFI..4: and so on). It generates the labels literally, i.e. the template __asm__ __volatile__(0: bne 0b) is translated into [...] 0: bne 0b instead of, for example, L0: bne L0 and then the assembler fails. I don't know what you expect GCC to do here. The contents of inline asm are passed through without modification, except for substituting % references. Note, the digit labels are a standard feature of the GNU assembler - which you are not using. which is exactly where the labels were emitted. GCC 3.4.4 has an additional bug/misfeature related with some missing instruction patterns: Assembler: /tmp//ccgioejq.s: line 538: 1252-149 Instruction lwarx is not implemented in the current assembly mode COM. Again, this error is coming from the AIX assembler, not from GCC. You ned to pass the correct options (I don't know what they are) to that assembler to make it accept these instructions. -- Daniel Jacobowitz CodeSourcery, LLC
