Re: question on arm soft-fp function __aeabi_d2uiz
"Amker.Cheng" writes: > I also tried the code on x86-cygwin, which prints 0x. > I am wondering why __aeabi_d2uiz returns 0 for negative double values. > Is this behavior defined by arm fpu and it's different with x86 in fpu > implementation? Converting a negative float value to an unsigned integer type results in undefined behaviour, so any result is valid. This is different from converting a negative integer value to unsigned, where the modulo rule is applied. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
illegal insn created in ira
Hi,
In my port I have an error: Before ira I have the following insn:
(insn 3859 4277 4366 57 (set (reg:BI 2038)
(subreg:BI (reg/v:SI 181 [ realsz ]) 3)) 76 {movbi}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
During ira this insn is transformed (I guess because reg 181 is spilled) into:
(insn 5109 5108 4366 57 (set (reg:BI 82 p1 [2038])
(mem/c:BI (plus:SI (reg/f:SI 79 r31)
(const_int -353 [0xfe9f])) [26 %sfp+-353
S1 A8])) 77 {movbi_load}
(nil))
The problem is that this is an illegal insn since the I don't have an
insn which loads from memory to P registers so I get error:
unrecognizable insn.
I have only insns which load from memory to R register class and insn
that moves from R to P and I expected that to happen.
I also tried to add to secondary reload things like:
if (rclass == P_REGS && MEM_P(x))
return R_REGS;
or
if ((rclass == P_REGS) && (((GET_CODE(x) == SUBREG) && MEM_P(XEXP (x, 0)
{
return R_REGS;
}
but it does not seem to help.
Does anyone have any idea what can I do?
Thanks, Roy.
Re: GAS GCC FAQ query
On Fri, 6 May 2011, Jonathan Wakely wrote: >> I would propose to clarify as: >> >> "To ensure that GCC finds the GNU assembler (or the GNU linker)," > I see no harm in that change, Gerald, what do you think? Agreed. Things would have been different twenty years ago, but these days using linker is a lot more natural and common (as a grep in gcc/doc confirms, too). I went ahead and applied the patch below. Thanks for suggesting this! Gerald Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.211 diff -u -r1.211 faq.html --- faq.html30 May 2010 15:37:32 - 1.211 +++ faq.html8 May 2011 13:01:04 - @@ -218,14 +218,14 @@ GCC can not find GNU as/GNU ld -GCC searches the PATH for an assembler and a loader, but it only +GCC searches the PATH for an assembler and a linker, but it only does so after searching a directory list hard-coded in the GCC executables. Since, on most platforms, the hard-coded list includes -directories in which the system assembler and loader can be found, you +directories in which the system assembler and linker can be found, you may have to take one of the following actions to arrange that GCC uses the GNU versions of those programs. -To ensure that GCC finds the GNU assembler (the GNU loader), which +To ensure that GCC finds the GNU assembler (the GNU linker), which are required by http://gcc.gnu.org/install/specific.html";>some configurations, you should configure these with the same --prefix option as you used
Re: GAS GCC FAQ query
> Agreed. Things would have been different twenty years ago, but these > days using linker is a lot more natural and common (as a grep in gcc/doc > confirms, too). Even 20 years ago, I think "linker" would have been the more natural word. I remember "linker" from my IBM days in the early 80's.
numerical results differ after irrelevant code change
On a CentOS box with: # uname -a Linux xx 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686 i686 i386 GNU/Linux # gcc --version gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) and using: Template Numerical Toolkit (TNT). as well as numerical software I have written, all in C++, I am doing some voluminous and complex arithmetic. On two occasions I have encountered situations in which small, irrelevant modifications of the code result in small changes in the result. In a recent example, using type double, a result that is theoretically zero, is being approximated, reasonably, by a value of -1.16e-16. When an unused matrix variable member is added to a template class not used in that part of the calculations, the result is changed to -1.05e-16, also a reasonable result, but different. When the new variable is commented out, the difference disappears. The problem does not in itself compromise the usefulness of the result, but it does compromise confidence. Thanks for any suggestions. Mike. -- Michael D. Berger m.d.ber...@ieee.org
The Linux binutils 2.21.51.0.9 is released
This is the beta release of binutils 2.21.51.0.9 for Linux, which is
based on binutils 2011 0507 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.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:
http://sourceware.org/bugzilla/show_bug.cgi?id=12343
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
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.21.51.0.9 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.21.51.0.8:
1. Update from binutils 2011 0507.
2. Improve LTO bfd linker. PRs 12365/12696/12672
3. Fix a linker regression with constructor attribute in C++. PR 2730.
4. Warn relocation in readonly section when creating a shared object.
5. Remove empty output sections. PR 12718.
6. Remove DT_TEXTREL with local IFUNC symbols. PR 12694.
7. Properly set ELFOSABI_LINUX for STB_GNU_UNIQUE.
8. Fix objcopy on unusual input. PR 12632.
9. Fix an ar regression. PR 12720.
10 Avoid linker crash on bad linker input.
11. Fix a linker script regression. PR 12726.
12. Support new GNU DWARF extensions.
13. Initial support for SystemTap note sections.
14. Add --dwarf-start and --dwarf-end to readelf and objdump.
15. Disable 3dnow and 3dnowa for bdver1 in x86 assemble
Re: numerical results differ after irrelevant code change
On 5/8/2011 10:54 AM, Michael D. Berger wrote: On a CentOS box with: # uname -a Linux xx 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686 i686 i386 GNU/Linux # gcc --version gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) and using: Template Numerical Toolkit (TNT). as well as numerical software I have written, all in C++, I am doing some voluminous and complex arithmetic. On two occasions I have encountered situations in which small, irrelevant modifications of the code result in small changes in the result. In a recent example, using type double, a result that is theoretically zero, is being approximated, reasonably, by a value of -1.16e-16. When an unused matrix variable member is added to a template class not used in that part of the calculations, the result is changed to -1.05e-16, also a reasonable result, but different. When the new variable is commented out, the difference disappears. The problem does not in itself compromise the usefulness of the result, but it does compromise confidence. Thanks for any suggestions. This kind of result is quite expected on an x86 using the old style (default) floating-point (becauae of extra precision in intermediate results).
RE: numerical results differ after irrelevant code change
> -Original Message- > From: Robert Dewar [mailto:de...@adacore.com] > Sent: Sunday, May 08, 2011 11:13 > To: Michael D. Berger > Cc: gcc@gcc.gnu.org > Subject: Re: numerical results differ after irrelevant code change > [...] > > This kind of result is quite expected on an x86 using the old > style (default) floating-point (becauae of extra precision in > intermediate results). > How does the extra precision lead to the variable result? Also, is there a way to prevent it? It is a pain in regression testing. Thanks, Mike. -- Michael D. Berger m.d.ber...@ieee.org
Re: numerical results differ after irrelevant code change
On 5/8/2011 8:25 AM, Michael D. Berger wrote: -Original Message- From: Robert Dewar [mailto:de...@adacore.com] Sent: Sunday, May 08, 2011 11:13 To: Michael D. Berger Cc: gcc@gcc.gnu.org Subject: Re: numerical results differ after irrelevant code change [...] This kind of result is quite expected on an x86 using the old style (default) floating-point (becauae of extra precision in intermediate results). How does the extra precision lead to the variable result? Also, is there a way to prevent it? It is a pain in regression testing. If you don't need to support CPUs over 10 years old, consider -march=pentium4 -mfpmath=sse or use the 64-bit OS and gcc. Note the resemblance of your quoted differences to DBL_EPSILON from . That's 1 ULP relative to 1.0. I have a hard time imagining the nature of real applications which don't need to tolerate differences of 1 ULP. -- Tim Prince
RE: numerical results differ after irrelevant code change
Quoting "Michael D. Berger" : How does the extra precision lead to the variable result? Also, is there a way to prevent it? It is a pain in regression testing. Please read: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
RE: numerical results differ after irrelevant code change
-- Michael D. Berger m.d.ber...@ieee.org http://www.rosemike.net/ > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Tim Prince > Sent: Sunday, May 08, 2011 11:38 > To: gcc@gcc.gnu.org > Subject: Re: numerical results differ after irrelevant code change [...] > > How does the extra precision lead to the variable result? > > Also, is there a way to prevent it? It is a pain in > regression testing. > > > If you don't need to support CPUs over 10 years old, consider > -march=pentium4 -mfpmath=sse or use the 64-bit OS and gcc. > Note the resemblance of your quoted differences to > DBL_EPSILON from . That's 1 ULP relative to 1.0. I > have a hard time imagining the nature of real applications > which don't need to tolerate differences of 1 ULP. > I made the changes you suggest. While I was previously getting -1.16e-16 and -1.03e-16 depending presence of an "extra" class member, I now get 1.11e-16 (sic not -). But it is now independent of the extra class member, which is excellent. Hopefully, things will stay that way. Thanks, Mike.
Re: numerical results differ after irrelevant code change
On 5/8/2011 12:48 PM, Michael D. Berger wrote: I made the changes you suggest. While I was previously getting -1.16e-16 and -1.03e-16 depending presence of an "extra" class member, I now get 1.11e-16 (sic not -). But it is now independent of the extra class member, which is excellent. Hopefully, things will stay that way. This is a fairly big change to make in your program, since it completely alters the fpt semantics, but probably in a desirable way. Sounds like you don't have any real careful analysis of the reliability of the results or needed precision anyway, you just don't like the non-repeatability, and indeed the change to restrict the precision to 64-bits should work to solve that problem.
FW: numerical results differ after irrelevant code change
> -Original Message- > From: Robert Dewar [mailto:de...@adacore.com] > Sent: Sunday, May 08, 2011 13:02 > To: Michael D. Berger > Cc: gcc@gcc.gnu.org > Subject: Re: numerical results differ after irrelevant code change > > On 5/8/2011 12:48 PM, Michael D. Berger wrote: > > > I made the changes you suggest. While I was previously getting > > -1.16e-16 and -1.03e-16 depending presence of an "extra" > > class member, I now get 1.11e-16 (sic not -). But it is now > > independent of the extra class member, which is excellent. > Hopefully, > > things will stay that way. > > This is a fairly big change to make in your program, since it > completely alters the fpt semantics, but probably in a > desirable way. Sounds like you don't have any real careful > analysis of the reliability of the results or needed > precision anyway, you just don't like the non-repeatability, > and indeed the change to restrict the precision to 64-bits > should work to solve that problem. > As I should have said originally, I just did the -march=pentium4 -mfpmath=sse, I didn't change to a 64 bit system. Will that get the repeatabiility? It has on the brief test I did. Thanks, Mike.
gcc-4.3-20110508 is now available
Snapshot gcc-4.3-20110508 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110508/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 173552 You'll find: gcc-4.3-20110508.tar.bz2 Complete GCC (includes all of below) MD5=bb88875a7a3acee65d58d8889b50888e SHA1=dffd659f6257a3e3dc22ad9a218f192832761c90 gcc-core-4.3-20110508.tar.bz2C front end and core compiler MD5=991ae0452ef967f94fdaf59fa26770f4 SHA1=507f87fa98732cfe622b4aee4ca4750849baa2ad gcc-ada-4.3-20110508.tar.bz2 Ada front end and runtime MD5=e3c977704210d31cd415f159c5d16082 SHA1=2c52c4909e1b48a803da1cbc346907437344a5ac gcc-fortran-4.3-20110508.tar.bz2 Fortran front end and runtime MD5=3584c35b206f7c474cb955c3767d9b86 SHA1=b2ba7e509b270579585714eca90904ec02351937 gcc-g++-4.3-20110508.tar.bz2 C++ front end and runtime MD5=def9a971a4f546dac2d2e122fd30cd49 SHA1=f2424f3bac0544bdce4870f8fca8dc1721f8a804 gcc-go-4.3-20110508.tar.bz2 Go front end and runtime MD5=c30fef605b40ece730dc07d7f60b732f SHA1=732b706a6b0a20eddedd93cd3a9b23673410a245 gcc-java-4.3-20110508.tar.bz2Java front end and runtime MD5=10de5a076cffaf09febf790036d0916d SHA1=49dd89d4f045aae2eef53c93fad2cfbe289e2ede gcc-objc-4.3-20110508.tar.bz2Objective-C front end and runtime MD5=d548be19c39e8ff74356fc47a1886892 SHA1=42a545fcf90cf14d9a3ccdc4b0ab93ed25d49aed gcc-testsuite-4.3-20110508.tar.bz2 The GCC testsuite MD5=4c2a3597b9c4849291c725a6dd822b74 SHA1=ee94e074d5b10cfdbf47dabf1d635a12c8c1cbd8 Diffs from 4.3-20110501 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: FW: numerical results differ after irrelevant code change
On 5/8/2011 3:01 PM, Michael D. Berger wrote: As I should have said originally, I just did the -march=pentium4 -mfpmath=sse, I didn't change to a 64 bit system. Will that get the repeatabiility? It has on the brief test I did. Right, if you specify sse, you get totally different floating-point accuracy semantics by limiting the precision to 64-bits (this has nothing whatever to do with being on a 64-bit machine) and it should give better reproducability. Thanks, Mike.
Re: GAS GCC FAQ query
Gerald Pfeifer wrote, On 08/05/11 14:02: On Fri, 6 May 2011, Jonathan Wakely wrote: I would propose to clarify as: "To ensure that GCC finds the GNU assembler (or the GNU linker)," I see no harm in that change, Gerald, what do you think? Agreed. Things would have been different twenty years ago, but these days using linker is a lot more natural and common (as a grep in gcc/doc confirms, too). I went ahead and applied the patch below. Thanks for suggesting this! Great the change has been made Gerald, Jonathan, thank you. Best regards, Jon
Re: gcc detect multiple -o passed on one command line
Dave Korn wrote, On 07/05/11 16:01: On 06/05/2011 09:00, Andreas Schwab wrote: Ian Lance Taylor writes: The difference is that with -E the -o option is passed to cc1, whereas without it the -o option is passed to the assembler or the linker. The GNU assembler and linker both have the usual Unix behaviour of only using the last -o option. Nevertheless it might be a good idea to file a bug for binutils. Consistency is probably more important, and it helps in case of typos. In this case, I don't think consistency should win over maintaining long-established behaviour. I'm more inclined to say that cc1 should change to follow long-established *nix tradition. (I have absolutely found it useful on at least one occasion to be able to add a -o option into CFLAGS and know it would come last on the command-line and win.) Hello Would it be useful to have an option to enable warning if there are duplicates? From my point of view, I feel that not warning duplicates may let mistakes in the way gcc is invoked slip through, e.g. assist tracking down these issues in makefiles. Best regards, Jon
Re: gcc detect multiple -o passed on one command line
On 5/8/2011 6:23 PM, Jon Grant wrote: Hello Would it be useful to have an option to enable warning if there are duplicates? From my point of view, I feel that not warning duplicates may let mistakes in the way gcc is invoked slip through, e.g. assist tracking down these issues in makefiles. My feeling is that it is so common to take advantage of the last-o-wins semantics that this warning would not be useful. Best regards, Jon
[PATCH] for Re: C99 and C++0x status pages
On Tue, 31 Aug 2010, Andre Majorel wrote: > Yesterday, I spent an hour looking for the C99 and C++0x status > pages in http://gcc.gnu.org/, > > http://gcc.gnu.org/c99status.html > http://gcc.gnu.org/projects/cxx0x.html > > Apparently, the shortest path to the latter is > > "Releases" > -> "GCC 4.5.1" > -> "GCC 4.5.1 Jul 31, 2010 (changes)" > -> "Improved experimental support for the upcoming C++0x" > -> "please see the C++0x in GCC project page" > > Those are among the most useful pages of the site, it makes no > sense to bury them 4+ levels deep. You're right, these two are really nice and for lack of proper landing pages for the C and C++ languages I went ahead and committed the patch below. Thanks for pointing this out, and sorry for the "slight" delay in getting back to you. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.800 diff -u -r1.800 index.html --- index.html 1 May 2011 21:26:47 - 1.800 +++ index.html 9 May 2011 00:30:51 - @@ -15,7 +15,9 @@ The GNU Compiler Collection includes front ends for -C, C++, Objective-C, Fortran, +C, +C++, +Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). GCC was originally written as the compiler for the
Re: gcc Pre-processor information
Hi Ian , you have helped to narrow my search but still finding it . . . Ian Lance Taylor-3 wrote: > > ankit writes: > >> Problem Statement : Given a C file which has several macros defined (eg. >> #define MACRO 10) . I need to know what all macros are defined and their >> usage point(eg. line number) in the code. >> >> Need to know this information during or after gcc pre-processing phase. >> >> Possible solution may dump this macro information in some file. >> >> Is there any way that gcc can dump this information and if yes how? > > Look at the implementation of -dD and the implementation of -g3. gcc > does have this information, though it may not be in a particularly > convenient form. > > Ian > > -- View this message in context: http://old.nabble.com/gcc-Pre-processor-information-tp31558009p31573904.html Sent from the gcc - Dev mailing list archive at Nabble.com.
