[PING] Re: Patch for Re: out of date docs?
On Mon, 3 Nov 2008, Rainer Orth wrote:
>>> I believe that this is false these days. I believe that it has been
>>> false since a cross-compiler to the alpha required a 64-bit
>>> HOST_WIDE_INT, which was in gcc 3.4.
>> Does this mean you (or Rainer) would approve the following documentation
>> update? ;-)
> at least I can't since I've never built cross-compilers to
> alpha-dec-osf, so I cannot say if it's true or not.
Ian? Okay to commit?
2008-11-18 Gerald Pfeifer
* doc/install.texi (alpha*-dec-osf*): Remove note on 32-bit
hosted cross-compilers generating less efficient code.
Index: doc/install.texi
===
--- doc/install.texi(revision 143097)
+++ doc/install.texi(working copy)
@@ -2798,14 +2798,6 @@
new version of DEC Unix, you should rebuild GCC to pick up the new version
stamp.
-Note that since the Alpha is a 64-bit architecture, cross-compilers from
-32-bit machines will not generate code as efficient as that generated
-when the compiler is running on a 64-bit machine because many
-optimizations that depend on being able to represent a word on the
-target in an integral value on the host cannot be performed. Building
-cross-compilers on the Alpha for 32-bit machines has only been tested in
-a few cases and may not work properly.
-
@samp{make compare} may fail on old versions of DEC Unix unless you add
@option{-save-temps} to @code{BOOT_CFLAGS}. On these systems, the name
of the assembler input file is stored in the object file, and that makes
Re: Xtensa port maintainer
On Tue, Jan 6, 2009 at 12:37 AM, Kaveh R. GHAZI wrote: > Sorry I missed this back when it was originally posted, and the other SC > members likely did also. I'll try and get you going. The request was forwarded to the GCC SC. David
Re: [PING] Re: Patch for Re: out of date docs?
Gerald Pfeifer writes: > 2008-11-18 Gerald Pfeifer > > * doc/install.texi (alpha*-dec-osf*): Remove note on 32-bit > hosted cross-compilers generating less efficient code. This is OK. Thanks. Ian
Re: Tru64 non-virtual thunks multiply defined
Hi Nathan, Thanks for replying. I did not manage to get gcc trunk built on the Tru64 machine to confirm that it is still a problem (out of memory in stage2 compiling fold-const.c, but that's a whole different issue). On Mon, Jan 05, 2009 at 06:15:07PM -0800, Nathan Sidwell wrote: > Peter O'Gorman wrote: > > Is this patch itself to blame, or does it simply expose a latent bug? > > It is exposing a latent bug. There was a bug where multiple > logically-distinct > thunks were emitted even though they all had the same effect, and hence the > same > names. > I think I failed to be clear enough. Before this patch, thunks pointing to weak functions on Tru64 were weak, after it, the functions remain weak, but the thunks are not. This is problematic. For example, after compiling the attachment to PR38581: % nm -Bw f.o | grep N3MI1D0 | c++filt 0x00 N $_ZN3MI1D0Ev..ng 0x00 N $_ZThn8_N3MI1D0Ev..ng 0x00 N $_ZTv0_n32_N3MI1D0Ev..ng 0x000af8 T* MI1::~MI1() 0x000ae4 T non-virtual thunk to MI1::~MI1() 0x000ac8 T virtual thunk to MI1::~MI1() Since the destructor is weak (the * indicates weak), the thunks should also be, and when we revert your fix, they are, indeed, all weak. We don't have this problem with the same compiler version on AIX, HP-UX, IRIX, Linux or Solaris, and since you say that it's a latent bug, it does seems likely to be some issue with just the Tru64/alpha target. > > Will reverting this patch in the gcc that we ship cause any real > > problems? > > Yes, it may cause the thunks to be placed far from the thunked-to function and > hence have jump range problems. Perhaps that's not an issue on Tru64 though Ok, depends on exactly how far away, I guess :). We haven't run into it, so we can cross our fingers and hope. Until we can find the real bug though it seems better for us to have a working compiler than a semi-working one :/. Probably best to leave further discussion to the bug report now. Thank you, Peter -- Peter O'Gorman po...@thewrittenword.com
Re: Tru64 non-virtual thunks multiply defined
Peter, > I think I failed to be clear enough. Before this patch, thunks > pointing to weak functions on Tru64 were weak, after it, the functions > remain weak, but the thunks are not. This is problematic. ah, I failed to appreciate that. That sounds like a proble with the patch. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery
The Linux binutils 2.19.51.0.1 is released
This is the beta release of binutils 2.19.51.0.1 for Linux, which is
based on binutils 2009 0106 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
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.19.51.0.1 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.50.0.1:
1. Update from binutils 2009 0106.
2. Support AVX Programming Reference (December, 2008)
2. Encode AVX insns with 2byte VEX prefix if possible.
4. Add .s suffix support to swap register operands to x86 assembler.
5. Properly select NOP insns for code alignment in x86 assembler.
6. Fix 2 symbol visibility linker bugs. PRs 9676/9679.
7. Fix an ia64 linker relaxation bug. PR 7036.
8. Fix a symbol versioning bug. PR 7047.
9. Fix unitialized data in linker. PR 7028.
10. Avoid a linker crash on bad input. PR 7023.
11. Fix a linker memory leak. PR 7012.
12. Fix strip/objcopy crash on PT_GNU_RELRO. PR 7011.
13. Improve MacOS support.
14. Fix a COFF linker bug. PR 6945.
15. Add LM32 support.
16. Fix various arm bugs.
17. Fix various avr bugs.
18. Fix various CR16 bugs.
19. Fix various cris bugs.
20. Fix various m32c bugs.
21. Fix various m68k bugs.
22. Fix various mips bugs.
23. Fix various ppc bugs.
24. Fix various s390 bugs.
25. Fix various sparc bugs.
26. Fix various spu bugs.
27. Fix various xtensa bugs.
The file list:
1. binutils-2.19.51.0.1.tar.bz2. Source code.
2. binutils-2.19.50.0.1-2.19.51.0.1.diff.bz2. Patch against the
previous beta source code.
3. binutils-2.19.51.0.1.i686.tar.bz2. IA-32 binary tar ball for RedHat
EL 4.
4. binutils-2.19.51.0.1.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 4.
5. binutils-2.19.51.0.1.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
01/06/2009
GCC 4.4.0 Status Report (2009-01-06)
Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. As stated previously, the GCC 4.4 branch will be created when there are no open P1s and the total number of P1, P2, and P3 regressions is under 100. One issue that remains is removing the old register allocator. Vladimir, it's time to do this finally. Quality Data Priority # Change from Last Report --- --- P1 12 + 7 P2 112 + 12 P34 + 4 --- --- Total 128 + 23 Holiday season has caused quite an increase in the number of regressions. This gives us the opportunity to continue fixing regressions for 4.4.0 some more. Previous Report === http://gcc.gnu.org/ml/gcc/2008-12/msg00131.html The next report for 4.4.0 will be sent by Jakub. Richard.
Re: Thomas Schwinge appointed GNU Hurd maintainer
Hello! On Mon, Dec 01, 2008 at 01:36:58PM -0500, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Thomas Schwinge as GCC maintainer for GNU Hurd. > > Please join me in congratulating Thomas on his new role. > Thomas, please update your listing in the MAINTAINERS file. I committed the following: 2009-01-06 Thomas Schwinge * MAINTAINERS (OS Port Maintainers): Add myself for GNU/Hurd. (Write After Approval): Remove myself. Index: MAINTAINERS === --- MAINTAINERS (revision 143137) +++ MAINTAINERS (revision 143138) @@ -105,6 +105,7 @@ darwin portStan Shebs stansh...@earthlink.net DJGPP DJ Delorie d...@delorie.com freebsdLoren J. Rittle ljrit...@acm.org +GNU/Hurd Thomas Schwinge tschwi...@gnu.org hpux John David Anglin dave.ang...@nrc-cnrc.gc.ca hpux Steve Ellceys...@cup.hp.com irix, osf Rainer Orth r...@techfak.uni-bielefeld.de @@ -426,7 +427,6 @@ Silvius Rusr...@google.com Matthew Sachs msa...@apple.com Duncan Sands baldr...@gcc.gnu.org -Thomas Schwingetschwi...@gnu.org Dodji Seketeli dseke...@redhat.com Svein Seldal sv...@dev.seldal.com Thiemo Seufer t...@networkno.de Regards, Thomas signature.asc Description: Digital signature
m32c, ivopts, 20000412-6.c
I'm looking a failure for m32c-elf (-mcpu=m32c) in gcc.c-torture/execute/2412-6.c. I've narrowed it down to a transformation done in 107t.ivopts. In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values): tmp_9 = tmp_16 + 2; if (bufend_6(D) > tmp_9) but in 107t.ivopts: tmp_9 = tmp_16 + 2; D.1229_1 = (unsigned int) tmp_9; tmp_13 = (short unsigned int *) D.1229_1; if (bufend_6(D) > tmp_13) The problem is that tmp_9 is a 24-bit value, and casting it to unsigned int (16 bits) truncates off eight of the bits. Why are we casting pointers to integer values at all? Is there any way to stop ivopts from performing this truncation?
Question about UNSPEC rtx and a new instruction
Hello, I am working on a gcc porting for a new instruction. This instruction needs to move data from memory to two registers. So I use the SET rtx, and the dest of SET is an UNSPEC rtx with two registers. By using such a rtl pattern, gcc performs very differently. It makes mistakes for register replacement and instruction reordering. For example, when gcc optimizes in pass_cse, it performs register substitution of registers in UNSPEC rtx without checking the validity of the resulting insn. So I wonder about the UNSPEC rtx. What's the usage of UNSPEC rtx? And do you have a better rtl pattern for this new instruction? Thanks, Jacy
RE: How to define 2 bypasses for a single pair of insn_reservation
Maxim and Vladimir Wrote: >>> Anyone can help me through this please? >>> >> It was supposed to have two latency definitions at most (one in >> define_insn_reservation and another one in define_bypass). That time it >> seemed enough for all processors supported by GCC. It also simplified >> semantics definition when two bypass conditions returns true for the >> same insn pair. >> >> If you really need more one bypass for insn pair, I could implement >> this. Please, let me know. In this case semantics of choosing latency >> time could be >> >> o time in first bypass occurred in pipeline description whose condition >> returns true >> o time given in define_insn_reservation > > I had a similar problem with ColdFire V4 scheduler model and the > solution for me was using adjust_cost() target hook; it is a bit > complicated, but it works fine. Search m68k.c for 'bypass' for more > information, comments there describe the thing in sufficient detail. Maxim, I read your implementation in m68k.c. IMHO it is a smart but tricky solution. For example it depends on the assumption that targetm.sched.adjust_cost () immediately called after bypass_p(). Also the redundant check and calls to min_insn_conflict_delay looks inefficient. I'd prefer to extend semantics to support more than one bypass. Thanks - Joey
RE: How to define 2 bypasses for a single pair of insn_reservation
Vladimir Makarov [mailto:vmaka...@redhat.com] wrote: > It was supposed to have two latency definitions at most (one in > define_insn_reservation and another one in define_bypass). That time it > seemed enough for all processors supported by GCC. It also simplified > semantics definition when two bypass conditions returns true for the > same insn pair. > > If you really need more one bypass for insn pair, I could implement > this. Please, let me know. In this case semantics of choosing latency > time could be > > o time in first bypass occurred in pipeline description whose condition > returns true > o time given in define_insn_reservation Maxim and I encountered the same problem, and I believe we won't be the last two unlucky guys. Can you please implement the extended semantics, which looks good to me? Thank s- Joey
Re: How to define 2 bypasses for a single pair of insn_reservation
Ye, Joey wrote: Maxim and Vladimir Wrote: Anyone can help me through this please? It was supposed to have two latency definitions at most (one in define_insn_reservation and another one in define_bypass). That time it seemed enough for all processors supported by GCC. It also simplified semantics definition when two bypass conditions returns true for the same insn pair. If you really need more one bypass for insn pair, I could implement this. Please, let me know. In this case semantics of choosing latency time could be o time in first bypass occurred in pipeline description whose condition returns true o time given in define_insn_reservation I had a similar problem with ColdFire V4 scheduler model and the solution for me was using adjust_cost() target hook; it is a bit complicated, but it works fine. Search m68k.c for 'bypass' for more information, comments there describe the thing in sufficient detail. Maxim, I read your implementation in m68k.c. IMHO it is a smart but tricky solution. For example it depends on the assumption that targetm.sched.adjust_cost () immediately called after bypass_p(). Yes, it does depend on this assumption and the comment states exactly that. Also the redundant check and calls to min_insn_conflict_delay looks inefficient. Which check[s] do you have in mind, the gcc_assert's? Also, out of curiosity, what is inefficient about the use of min_insn_conflict_delay? For the record, min_insn_conflict delay has nothing to do with emulating two bypasses; this tweak makes scheduler faster by not adding instructions to the ready list which makes haifa-sched.c:max_issue() do its exhaustive-like search on a smaller set. I'd prefer to extend semantics to support more than one bypass. Don't get me wrong, I'm not against adding support for N>1 bypasses; it is not that easy though ;) . -- Maxim
RE: How to define 2 bypasses for a single pair of insn_reservation
Maxim Kuvyrkov [mailto:ma...@codesourcery.com] wrote: > Yes, it does depend on this assumption and the comment states exactly that. What I concerned is that the assumption may be broken someday, unless scheduler guarantees it. > Which check[s] do you have in mind, the gcc_assert's? Also, out of > curiosity, what is inefficient about the use of min_insn_conflict_delay? > > For the record, min_insn_conflict delay has nothing to do with emulating > two bypasses; this tweak makes scheduler faster by not adding > instructions to the ready list which makes haifa-sched.c:max_issue() do > its exhaustive-like search on a smaller set. I admit your implementation is probably the best correct solution based on current semantic. I'm just too lazy to like wrting that additional code and defining new data structure, especially after Vladimir said he could extend the semantic ;) > Don't get me wrong, I'm not against adding support for N>1 bypasses; it > is not that easy though ;) . No idea about the effort. But I guess you'd like to re-implement m68k with the 2nd bypass when it is ready. Thanks - Joey
Re: libmudflap and emutls question
> +AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
> + [if grep __emutls_get_address conftest.$ac_objext
> >/dev/null ; then
grepping in a binary file is not portable. If this works it would be
better:
AC_COMPILE_IFELSE([[__thread int a; int b;
extern void __emutls_get_address();
int main() {
__emutls_get_address();
return a = b;
}]],
[gcc_cv_use_emutls=yes],
[gcc_cv_use_emutls=no])
Otherwise, the configury parts look fine to me.
Paolo
