building glibc-2.4 for alpha fails with "macro requires $at register while noat in effect"
i was trying to cross-compile glibc-2.4 with gcc-4.1.1 when it failed on me
while building ioperm.c ... poking around a bit, looks like the same issue
discussed here:
http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html
however, this seems to have stalled ?
the glibc build system appends -Wa,-mev6 to the CFLAGS for ioperm.c, but when
gcc is run without a -mcpu flag (or with ev4/ev5 specified), the resulting
asm produced includes '.arch ev4' or '.arch ev5', and then gas aborts with
the fun errors:
{standard input}: Assembler messages:
{standard input}:181: Error: macro requires $at register while noat in effect
{standard input}:199: Error: macro requires $at register while noat in effect
{standard input}:235: Error: macro requires $at register while noat in effect
{standard input}:255: Error: macro requires $at register while noat in effect
and of course, adding -mcpu=ev6 or better to CFLAGS works just peachy
-mike
pgpkHs0qKbu4H.pgp
Description: PGP signature
Re: building glibc-2.4 for alpha fails with "macro requires $at register while noat in effect"
Mike Frysinger <[EMAIL PROTECTED]> writes:
> i was trying to cross-compile glibc-2.4 with gcc-4.1.1 when it failed on me
> while building ioperm.c ... poking around a bit, looks like the same issue
> discussed here:
> http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html
> however, this seems to have stalled ?
>
> the glibc build system appends -Wa,-mev6 to the CFLAGS for ioperm.c, but when
> gcc is run without a -mcpu flag (or with ev4/ev5 specified), the resulting
> asm produced includes '.arch ev4' or '.arch ev5', and then gas aborts with
> the fun errors:
> {standard input}: Assembler messages:
> {standard input}:181: Error: macro requires $at register while noat in effect
> {standard input}:199: Error: macro requires $at register while noat in effect
> {standard input}:235: Error: macro requires $at register while noat in effect
> {standard input}:255: Error: macro requires $at register while noat in effect
>
> and of course, adding -mcpu=ev6 or better to CFLAGS works just peachy
The cheap fix is to have gcc not emit .arch ev4. I was planning on
testing and submitting the following patch for this, but gcc didn't
bootstrap for a few days...
--
Falk
Index: alpha.c
===
--- alpha.c (revision 115263)
+++ alpha.c (working copy)
@@ -9372,7 +9372,7 @@
fputs ("\t.set nomacro\n", asm_out_file);
if (TARGET_SUPPORT_ARCH | TARGET_BWX | TARGET_MAX | TARGET_FIX | TARGET_CIX)
{
- const char *arch;
+ const char *arch = NULL;
if (alpha_cpu == PROCESSOR_EV6 || TARGET_FIX || TARGET_CIX)
arch = "ev6";
@@ -9382,10 +9382,9 @@
arch = "ev56";
else if (alpha_cpu == PROCESSOR_EV5)
arch = "ev5";
- else
- arch = "ev4";
- fprintf (asm_out_file, "\t.arch %s\n", arch);
+ if (arch)
+fprintf (asm_out_file, "\t.arch %s\n", arch);
}
}
#endif
Re: building glibc-2.4 for alpha fails with "macro requires $at register while noat in effect"
On Saturday 15 July 2006 05:12, Falk Hueffner wrote: > The cheap fix is to have gcc not emit .arch ev4. I was planning on > testing and submitting the following patch for this, but gcc didn't > bootstrap for a few days... that'd work for default/ev4 targets (no -mcpu or -mcpu=ev4), but poor old ev5's would still be broken :) -mike pgp2sFREkjCor.pgp Description: PGP signature
Re: building glibc-2.4 for alpha fails with "macro requires $at register while noat in effect"
Mike Frysinger <[EMAIL PROTECTED]> writes: > On Saturday 15 July 2006 05:12, Falk Hueffner wrote: >> The cheap fix is to have gcc not emit .arch ev4. I was planning on >> testing and submitting the following patch for this, but gcc didn't >> bootstrap for a few days... > > that'd work for default/ev4 targets (no -mcpu or -mcpu=ev4), but poor old > ev5's would still be broken :) Oh, right. Those two lines should also go. Which would still leave broken the case of -mcpu=ev56, when you use ev6 instructions. Fixing that would take some more effort, either dropping the ".arch" mechanism and passing as options from gcc, or fiddling with binutils to have command line arguments override ".arch". -- Falk
Re: RFD: language hooks in GIMPLE / lang_flag?
On 7/15/06, Richard Kenner <[EMAIL PROTECTED]> wrote: > OK. But, GIMPLE is also supposed to be type-safe, so I wouldn't think > that "int = long" would be well-formed gimple. ... or we *could* define it that way. My point is just that whatever type "compatibility" might mean at the GIMPLE level, it should just be a function of whether the types will produce different code, not something at the language level. The qustion of what we use the compatible types test for is different. I wasn't suggesting (at this point at least!) that it be changed, but didn't research exactly when it's used either. For most parts of the middle-end treating type compatibility as equivalence of machine modes (for basic types, that is) should be ok. Of course to not lose alias information it needs to be attached to the proper objects (decls and memory references) by the frontends and propagated accordingly. Richard.
Bootstrap broken on ppc-darwin
/Users/regress/tbox/native/build/./gcc/xgcc -shared-libgcc -B/Users/ regress/tbox/native/build/./gcc -nostdinc++ -L/Users/regress/tbox/ native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/src -L/Users/ regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/ src/.libs -B/Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/bin/ - B/Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/lib/ -isystem / Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/include -isystem / Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/sys-include -I/ Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++- v3/include/powerpc-apple-darwin8.5.0 -I/Users/regress/tbox/native/ build/powerpc-apple-darwin8.5.0/libstdc++-v3/include -I/Users/regress/ tbox/svn-gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall - Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once - ffunction-sections -fdata-sections -g -O2 -I/Users/regress/tbox/ native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/include/backward - Wno-deprecated -c /Users/regress/tbox/svn-gcc/libstdc++-v3/src/ strstream.cc -fno-common -DPIC -o .libs/strstream.o /tmp/ccK4i3re.s:5107:FATAL:Symbol LFBB43 already defined. I think it was: 2006-07-14 Carlos O'Donell <[EMAIL PROTECTED]> * dbxout.c (dbxout_begin_prologue): Emit LFBB label at function start. (dbxout_function_end): Use local label LFBB. Remove hook DBX_OUTPUT_NFUN. (dbxout_source_line): Use local label LFBB. (dbxout_block): Likewise. (dbx_output_lbrac): Remove hook DBX_OUTPUT_LBRAC. (dbx_output_rbrac): Remove hook DBX_OUTPUT_RBRAC. * config/rs6000/linux64.h: Remove DBX_OUTPUT_LBRAC, DBX_OUTPUT_RBRAC, and DBX_OUTPUT_NFUN. But I have not looked to make sure. Note this was after a day after Geoff's regression machine finally had no regressions so this is slightly disappointing. Thanks, Andrew Pinski
Re: expand_divmod algorithm patented?
* Joern Rennecke: > PJ has posted a news pick on Groklaw about a new patent which, afar as I can > tell, claims the algorithm that Tege has contributed to expmed.c:expand_divmod > in 1994 (r7598) > http://www.freshpatents.com/Method-and-apparatus-for-efficient-software-based-integer-division-dt20060504ptan20060095494.php This is just a patent application. It's not very likely it will be granted as-is.
Re: Bootstrap broken on ppc-darwin
> /tmp/ccK4i3re.s:5107:FATAL:Symbol LFBB43 already defined. Same breakage on SPARC/Solaris 2.[56] and Alpha/Tru64. -- Eric Botcazou
config/gnu.h, config/i386/gnu.h don't include copyright notices
Is there a reason why both config/gnu.h and config/i386/gnu.h don't include copyright notices or even the license they are under. Does that mean they are in the public domain or did someone mess up when contributing them? Thanks, Andrew Pinski
Re: config/gnu.h, config/i386/gnu.h don't include copyright notices
Is there a reason why both config/gnu.h and config/i386/gnu.h don't include copyright notices or even the license they are under. Does that mean they are in the public domain or did someone mess up when contributing them? They are (or were) non-trivial enough not to require a copyright notice.
Re: config/gnu.h, config/i386/gnu.h don't include copyright notices
They are (or were) non-trivial enough not to require a copyright notice. I obviously mean that they were _trivial_ enough not to require a copyright notice.
Re: config/gnu.h, config/i386/gnu.h don't include copyright notices
On Jul 16, 2006, at 12:49 AM, Alfred M. Szmidt wrote: They are (or were) non-trivial enough not to require a copyright notice. Then why does config/rs6000/gnu.h have one, it is more trivial than the others. -- Pinski
Re: gcc visibility used by moz
Geoffrey Keating wrote: Jason Merrill <[EMAIL PROTECTED]> writes: Benjamin Smedberg wrote: Also, do you agree with warning about a class with greater visibility than its data members/bases? Sure... I would really like to disable this warning if possible, since it will be produced thousands of times in a mozilla build ;-) I find that surprising, since it sounds like VC++ gives the same warning about a dllexport class with a non-dllexport base. I think that if the aim is to have VC++ compatibility, that should be separate from the 'right' solution. Absolutely. I didn't put in that warning because it was in VC++, but I wouldn't expect it to introduce new warnings moving code from VC++ to g++. Jason
gcc-4.2-20060715 is now available
Snapshot gcc-4.2-20060715 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060715/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 115481 You'll find: gcc-4.2-20060715.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060715.tar.bz2 C front end and core compiler gcc-ada-4.2-20060715.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060715.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060715.tar.bz2 C++ front end and runtime gcc-java-4.2-20060715.tar.bz2 Java front end and runtime gcc-objc-4.2-20060715.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060715.tar.bz2The GCC testsuite Diffs from 4.2-20060708 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: A correction: Different invariants about the contents of static links]
OK, Thanks for the information. Just in case, does anybody already
have it in their head roughly where in gcc code this decision is made?
Ian Lance Taylor wrote:
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
When executing in foo, the frame pointer will point to a fixed spot in the
activation record of foo. On i386, the FP is %ebx and it points to the
dynamic link field. From there, loc is at displacement -4. Code in the
body of foo will reference x at -4(FP).
When we get into any instance of s1, s1's AR will contain a static link that
points to the AR of foo, which is what you said. The question is where
in foo's AR does the SL point to. It would make sense for it to be the same
as where the frame pointer points when executing in foo, i.e., the static
link would point to the dynamic link field of foo's AR. Then x could be
accessed from within sl by loading the SL into some register, say REG, and
referring to -4(REG). loc is at the same displacement relative to the static
link in s1 as is used in foo relative to the FP.
Thanks for the explanation. I think I may now understand what you are
getting at.
Consider this slight adjustment to your example:
extern void bar (int *, int *);
int
foo (int x, int y)
{
int a;
int loc;
int b;
int
s1 ()
{
if (--y == 0)
return 0;
return loc + s1 ();
}
loc = x;
bar (&a, &b);
bar (&a, &b);
return s1 ();
}
When I compile this, the static chain is 24 bytes off from the frame
pointer. That example was just to show an aspect of how gcc
implements the activation record. gcc builds a struct holding all the
information which needs to be referenced. Then it passes the address
of that struct as the static chain.
If you pass a variable size object (e.g., int a[i]) then gcc will
store a pointer to that object in the activation record. gcc will
also store a pointer if you try to pass down a struct which is a
parameter in the calling function. These are examples where it isn't
obvious that we want the static chain pointer to be the same as the
frame pointer.
That said, I think I now agree that since the activation record always
has a constant size, we could make the static chain pointer always be
the same as the frame pointer. The users would apply a constant
offset to their static chain pointer to get to the activation record.
Issues would arise on processors with limited offset space in
addresses, but those issues are solvable.
This all executes correctly, even if it's a bit strange. But it has to take
extra trouble for the code generator to keep track of two different reference
addresses for the same AR and adjust SL offsets to be different from FP
offsets for the same AR. I can't see any benefit. It doesn't change the
set of fields a SL can access in the AR it points to a bit. Only the
displacements needed change.
Actually, it is not extra trouble for the code generator, it is less
trouble. The code generator simply builds an internal struct to serve
as the activation record, puts the struct on the stack, and makes the
static chain always be a pointer to that struct. The code generator
moves simple values into the struct, and stores pointers for complex
values. Then all references through the static chain are easy to
implement.
Making the static chain be the same as the frame pointer requires a
bit of extra work because the frame pointer can be eliminated to the
stack pointer (via the -fomit-frame-pointer option, which is the
default for some processors when optimizing). The static chain
pointer would have to be eliminated just as the frame pointer is.
And it wouldn't matter to me, except it's making it a lot more difficult
to give gdb the ability to execute gdb-user-typed calls on nested functions
and pass nested functions as parameters (where gdb has to generate static
link values) and print nonlocal variables (where gdb has to know how to
interpret the contents of a SL).
To make that work is going to take more than making the static chain
pointer and the frame pointer equivalent. You are going to have to
know how to build the activation record, which as we have seen can
contain pointers to variables which live in the frame.
So I think you are on the wrong path here. Instead of trying to
equate the static chain pointer and the frame pointer, I think what
you need to do is find some way for the debugging information to
describe the activation record, and to describe where it lives on the
stack.
Ian
--
Rodney M. Bates
The Linux binutils 2.17.50.0.3 is released
This is the beta release of binutils 2.17.50.0.3 for Linux, which is based on binutils 2006 0715 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.17.50.0.3 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.17.50.0.2: 1. Update from binutils 2006 0715. 2. Add --hash-style to ELF linker with DT_GNU_HASH and SHT_GNU_HASH. 3. Fix a visibility bug in ELF linker (PR 2884). 4. Properly fix the i386 TLS linker bug (PR 2513). 5. Add assembler and dissassembler support for Pentium Pro nops. 6. Optimize x86 nops for Pentium Pro and above. 7. Add -march=/-mtune= to x86 assembler. 8. Fix an ELF linker with TLS common symbols. 9. Improve program header allocation in ELF linker. 10. Improve MIPS, M68K and ARM support. 11. Fix an ELF linker crash when reporting alignment change (PR 2735). 12. Remove unused ELF section symbols (PR 2723). 13. Add --localize-hidden to objcopy. 14. Add AMD SSE4a and ABM new instruction support. 15. Properly handle illegal x86 instructions in group 11 (PR 2829). 16. Add "-z max-page-size=" and "-z common-page-size=" to ELF linker. 17. Fix objcopy for .tbss sections. Changes from binutils 2.17.50.0.1: 1. Update from binutils 2006 0526. 2. Change the x86-64 maximum page size to 2MB. 3. Support --enable-targets=all for 64bit target and host (PR 1485). 4. Properly update CIE/FDE length and align section for .eh_frame section (PR 2655/2657). 5. Properly handle removed ELF section symbols. 6. Fix an ELF linker regression introduced on 2006-04-21. 7. Fix an segfault in PPC ELF linker (PR 2658). 8. Speed up the ELF linker by caching the result of kept section check. 9. Properly create stabs section for ELF. 10. Preserve ELF program header when copying ELF files. 11. Properly handle ELF SHN_LOPROC/SHN_HIOS when checking section index (PR 2607). 12. Misc mips updates. 13. Misc arm updates. 14. Misc xtensa updates. 15. Fix an alpha assembler warning (PR 2598). 16. Fix assembler buffer overflow. 17. Properly disassemble sgdt/sidt for x86-64. Changes from binutils 2.16.91.0.7: 1. Update from binutils 2006 0427. 2. Fix an objcopy regression (PR 2593). 3. Reduce ar memory usage (PR 2467). 4. Allow application specific ELF sections (PR 2537). 5. Fix an i386 TLS linker bug (PR 2513). 6. Speed up ia64 linker by 1300X in some cases (PR 2442). 7. Check illegal immediate register operand in i386 assembler (PR 2533). 8. Fix a strings bug (PR 2584). 9. Better handle corrupted ELF files (PR 2257). 10. Fix a MIPS linker bug (PR 2267). Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker "--as-needed" (PR 2434). 5. Fix linker "-s" regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in >64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 225
LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
Hello!
I have a VERY simple example:
int f1 (int i) {i = (i-7)/9+3; return i;}
int f2 (int i) {i = (i-7)/9+3; return i;}
It could be reduced to:
int f1 (int i) {i = (i-7)/9+3; return i;}
int f2 (int i) {return f1 (i);}
Are there any ideas on how and where to add a target and language
independent code compaction pass into gcc?
Miguel
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Question of the LOG_LINKS field
I'm porting GCC 4.1.1 to a VLIW architecture.
I have to insert NOP instructions when data dependencies occurred.
So I wrote an algorithm as the following:
foreach(insn in all real insns) {
foreach(dep_insn in LOG_LINKS(insn)) {
if(INSN_DELETED_P(dep_insn)) continue;
stalls = insn_latency(dep_insn, insn);
distance = cycle_distance(dep_insn, insn);
if(stalls > distance)
emit proper NOP instructions before insn;
}
}
(This algorithm is performed in the hook `TARGET_ASM_FUNCTION_PROLOGUE')
The algorithm is highly dependent on the information of LOG_LINKS(insn).
But I found that there are not any dependecy info for `reload instructions'
because the register allocation pass and reloading pass are peformed after
the first insn scheduling pass.
For example, here are two insns which have true data dependency:
@(insn 25 2343 895 (set (reg:SI 25 rd1)
@(const_int 0 [0x0])) 15 {*movsi_const_dsp} (nil)
@(nil))
movilc .m0 rd1, #0 @ 25*movsi_const_dsp/1 [length = 4]
@(insn 895 25 33 (set (mem/c:SI (plus:SI (reg/f:SI 12 fp)
@(const_int -1204 [0xfb4c])) [0 S4 A32])
@(reg:SI 25 rd1)) 16 {*movsi_dsp} (nil)
@(nil))
stw .r0 rd1, *-fp[#1204]@ 895 *movsi_dsp/13 [length
= 4]
The `insn 895' is inserted by global register allocation pass.
So its LOG_LINKS field is empty because the insn didn't process by first
scheduling pass.
Should I write a violent algorithm to scan these data dependencies?
Are there any better solutions for this problem?
Thanks a lot.
[lto] factor code common to all builtin_function
I have a patch that factors code common to all builtin_function implementations. It is approved for trunk when we get to stage1. Are the developers involved in the lto branch interested in this patch? If so, I can port it. Best Regards, Rafael
