Re: Should -msse3 enable fisttp
Richard Henderson wrote:
On Tue, Oct 04, 2005 at 10:07:31AM -0700, Dale Johannesen wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809
The patch in the PR looks reasonable.
I committed it after fixing some grammar problems.
Tested with `make info'.
Paolo
2005-10-05 Billy Biggs <[EMAIL PROTECTED]>
Paolo Bonzini <[EMAIL PROTECTED]>
PR target/23809
* doc/extend.texi (x86 Built-ins): Document that -msse and friends
enable the instructions and not just the built-ins.
* doc/invoke.texi (x86 Options): Likewise.
Index: extend.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.267
diff -u -r1.267 extend.texi
--- extend.texi 22 Aug 2005 16:12:09 - 1.267
+++ extend.texi 5 Oct 2005 08:19:38 -
@@ -6466,6 +6466,14 @@
These built-in functions are available for the i386 and x86-64 family
of computers, depending on the command-line switches used.
+Note that, if you specify command-line switches such as @option{-msse},
+the compiler could use the extended instruction sets even if the built-ins
+are not used explicitly in the program. For this reason, applications
+which perform runtime CPU detection must compile separate files for each
+supported architecture, using the appropriate flags. In particular,
+the file containing the CPU detection code should be compiled without
+these options.
+
The following machine modes are available for use with MMX built-in functions
(@pxref{Vector Extensions}): @code{V2SI} for a vector of two 32-bit integers,
@code{V4HI} for a vector of four 16-bit integers, and @code{V8QI} for a
Index: invoke.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.682
diff -u -r1.682 invoke.texi
--- invoke.texi 5 Oct 2005 00:35:53 - 1.682
+++ invoke.texi 5 Oct 2005 08:19:39 -
@@ -9261,15 +9261,20 @@
@opindex mno-sse
@opindex m3dnow
@opindex mno-3dnow
-These switches enable or disable the use of built-in functions that allow
-direct access to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the
-instruction set.
-
[EMAIL PROTECTED] Built-in Functions}, for details of the functions enabled
-and disabled by these switches.
+These switches enable or disable the use of instructions in the MMX,
+SSE, SSE2 or 3DNow! extended instruction sets. These extensions are
+also available as built-in functions: see @ref{X86 Built-in Functions},
+for details of the functions enabled and disabled by these switches.
To have SSE/SSE2 instructions generated automatically from floating-point
-code, see @option{-mfpmath=sse}.
+code (as opposed to 387 instructions), see @option{-mfpmath=sse}.
+
+These options will enable GCC to use these extended instructions in
+generated code, even without @option{-mfpmath=sse}. Applications which
+perform runtime CPU detection must compile separate files for each
+supported architecture, using the appropriate flags. In particular,
+the file containing the CPU detection code should be compiled without
+these options.
@item -mpush-args
@itemx -mno-push-args
Expanding sh maintainership for Kaz Kojima
In accordance with the two maintainers of the sh port (Alexandre Oliva and Joern Rennecke) the steering committee is happy to extend Kaz Kojima's maintainership from the current sh-linux-gnu to also include "sh: libraries, configure.gcc, Makefiles". Congratulations, Kaz! Would you mind updating your entry in the MAINTAINERS file? Also, please accept my sincere apologies for the delay in announcing this. I thought I had done than in August, but apparently I had not. :-( Gerald
Re: GCC 4.1 Status Report (2005-10-02)
On October 4, 2005 02:46, Mark Mitchell wrote: > The number of bugs targeted at GCC 4.1 has declined to 225 from 250 in > my September 7th status report: > Mark, could you post the query you use for this? The query I've got gives me a list of 289 bugs. Thanks.
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > In accordance with the two maintainers of the sh port (Alexandre > Oliva and Joern Rennecke) the steering committee is happy to extend > Kaz Kojima's maintainership from the current sh-linux-gnu to also > include "sh: libraries, configure.gcc, Makefiles". > > Congratulations, Kaz! Would you mind updating your entry in the > MAINTAINERS file? Thanks a lot! BTW, where is the appropriate place to add it in the MAINTAINERS file? Is it enough to modify the currnet line like this?: @@ -96,7 +96,7 @@ freebsdLoren J. Rittle [EMAIL PROTECTED] netbsd Jason Thorpe[EMAIL PROTECTED] sco5, unixware, sco udkKean Johnston [EMAIL PROTECTED] -sh-linux-gnu Kaz Kojima [EMAIL PROTECTED] +sh-linux-gnu, sh libs Kaz Kojima [EMAIL PROTECTED] RTEMS PortsJoel Sherrill [EMAIL PROTECTED] RTEMS PortsRalf Corsepius [EMAIL PROTECTED] VxWorks ports Nathan Sidwell [EMAIL PROTECTED] Or should I add a new entry to the "Various Maintainers" part? Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
On Wed, 5 Oct 2005, Kaz Kojima wrote: > BTW, where is the appropriate place to add it in the MAINTAINERS > file? Is it enough to modify the currnet line like this?: The current line is under "OS Ports"; have you considered adding a new, third line for sh to the "CPU Port Maintainers" section? Gerald
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > The current line is under "OS Ports"; have you considered adding a > new, third line for sh to the "CPU Port Maintainers" section? Like this? @@ -76,6 +76,7 @@ s390 port Ulrich Weigand [EMAIL PROTECTED] sh portJoern Rennecke [EMAIL PROTECTED] sh portAlexandre Oliva [EMAIL PROTECTED] +sh libraries Kaz Kojima [EMAIL PROTECTED] sparc port Richard Henderson [EMAIL PROTECTED] sparc port David S. Miller davem@redhat.com sparc port Jakub Jelinek [EMAIL PROTECTED] Regards, kaz
Re: Ada question about PR 18434
Laurent GUERBY writes: > If I'm guessing correctly there are two solutions: > > 1/ Remove the default initialization in ada/osint.adb > - Running_Program : Program_Type := Unspecified; > + pragma Warnings (Off); > + Running_Program : Program_Type; > + pragma Warnings (On); > > This is not a long term solution, but local and should fix the problem > if my hypothesis is correct, Rainer could you try this one? I did, and for the first time for any 4.x version, the current 4.0 branch bootstrapped successfully on alpha-dec-osf5.1b :-) Testsuite results are here: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00190.html and Ada doesn't look too bad compared to my last 3.4 branch results of 20050606: http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00587.html === acats tests === FAIL: c250002 -FAIL: c37213f -FAIL: c37215f -FAIL: c380004 +FAIL: c456001 FAIL: c45624a FAIL: c45624b -FAIL: c460010 FAIL: c4a013a -FAIL: cd30001 +FAIL: c52010a +FAIL: c52102a +FAIL: c52102b +FAIL: c52102c +FAIL: c52102d +FAIL: c52104c +FAIL: c74209a +FAIL: c954026 +FAIL: ca11021 +FAIL: cc70a01 +FAIL: cc70a02 FAIL: cd30002 FAIL: cd5011m +FAIL: cxa4001 FAIL: cxa5a03 +FAIL: cxaca01 FAIL: cxg2002 FAIL: cxg2017 FAIL: cxg2020 === acats Summary === -# of expected passes 2307 -# of unexpected failures 15 +# of expected passes 2296 +# of unexpected failures 24 Now the question is how to fix this for real. Thanks alot. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
Re: Expanding sh maintainership for Kaz Kojima
On Wed, 5 Oct 2005, Kaz Kojima wrote: > Like this? Yes -- and you can also include configure.gcc and Makefiles. ;-) Gerald
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > Yes -- and you can also include configure.gcc and Makefiles. ;-) Ah. There is no room to include all, though. :-) How about sh libraries/configury Kaz Kojima [EMAIL PROTECTED] ? Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
On Wed, 5 Oct 2005, Kaz Kojima wrote: > Ah. There is no room to include all, though. :-) How about > > sh libraries/configuryKaz Kojima [EMAIL PROTECTED] > > ? Looks fine. Gerald
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: >> sh libraries/configury Kaz Kojima [EMAIL PROTECTED] >> >> ? > > Looks fine. Thanks! I'll send a patch to the list and check it in. Regards, kaz
Re: Ada question about PR 18434
> Now the question is how to fix this for real. As far as I can see, the binder is indeed generating a call to osint__m___elabb before osint___elabb, so this is probably working elsewhere because Running_Program is probably initialized by the loader. I would suggest reducing the bug as much as possible and opening a PR in bugzilla. A possible work around (cleaner than the one suggested by Laurent) would be to add a pragma Elaborate_Body in osint.ads Arno
target-defs.h / tm.h question
Hi, Is there any reason why *all* of the macros in target-defs.h are not conditionalized? target-defs.h is always included after tm.h, so if the target specific include sets any of the macros that are not protected in target-defs.h, they get overwritten. Yes, you are warned, so my question is, is the intent to only conditioalize those macros that have actually been defined ib the target header file and to adjust target-defs.h on a case by case basis, or should I just clean up target-defs.h and protect *all* of the macros from redefining what may have been set in tm.h? Thanks for any input. PS. The specific case I ran into was I needed to define TARGET_PROMOTE_FUNCTION_RETURN but target-defs.h was not protecting its definition thereof with a #ifndef. Kean
Re: target-defs.h / tm.h question
On Wed, 5 Oct 2005, Kean Johnston wrote: > Hi, > > Is there any reason why *all* of the macros in target-defs.h > are not conditionalized? target-defs.h is always included after > tm.h, so if the target specific include sets any of the macros > that are not protected in target-defs.h, they get overwritten. > Yes, you are warned, so my question is, is the intent to only > conditioalize those macros that have actually been defined > ib the target header file and to adjust target-defs.h on a > case by case basis, or should I just clean up target-defs.h > and protect *all* of the macros from redefining what may > have been set in tm.h? Are the comment /* Note that if one of these macros must be defined in an OS .h file rather than the .c file, then we need to wrap the default definition in a #ifndef, since files include tm.h before this one. */ and the description in tm.texi of these macros as defined in the .c file (not in tm.h) insufficiently clear about the principle? Ideally the conditional cases would be cleaned up so that the macros do get defined only in the .c files and their definitions become no longer visible to most of GCC. But it can be simpler when transitioning from target macros to the target structure to define the TARGET_* in tm.h as an interim state. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Types of allowed regions in sched-rgn.c
I'm interested in studying different region formation algorithms for the interblock scheduling code. Can someone please tell me the restrictions on the form of these regions? (i.e., what does the Haifa scheduler expect?) Specifically, I am interested in forming treegions (tree regions). If interested see this reference: W. A. Havanki, S. Banerjia and T. M. Conte, "Treegion scheduling for wide-issue processors," Proceedings of the 4th International Symposium on High-Performance Computer Architecture (HPCA-4), (Las Vegas), Feb. 1998. or H. Zhou and T.M. Conte, "Code Size Efficiency in Global Scheduling for ILP Processors," Proceedings of the 6th Annual Workshop on the Interaction between Compilers and Computer Architectures, February 2002. Thanks, Chad
Re: target-defs.h / tm.h question
Are the comment /* Note that if one of these macros must be defined in an OS .h file rather than the .c file, then we need to wrap the default definition in a #ifndef, since files include tm.h before this one. */ and the description in tm.texi of these macros as defined in the .c file (not in tm.h) insufficiently clear about the principle? Sarcasm unneccesary. Its a big file, I didnt read every line of it. But thank you for the reply it answered my question. Kean
