summaryrefslogtreecommitdiffstats
path: root/contrib/gcc/config/freebsd-spec.h
Commit message (Collapse)AuthorAgeFilesLines
* Locate __FreeBSD_cc_version's value beside __FreeBSD__'s value to make itobrien2005-10-301-1/+1
| | | | easier to keep them in sync.
* Catch up with FreeBSD 7.obrien2005-10-291-1/+1
|
* Submitted following patch to FSF GCC:rodrigc2005-10-271-10/+1
| | | | | | | | | * freebsd-spec.h (FBSD_TARGET_OS_CPP_BUILTINS): Use builtin_define_with_int_value() instead of adding a new check for every new major FreeBSD version. Motivated by: simon Discussed with: obrien, kan
* Merge conflicts for GCC 3.4.4.kan2005-06-031-16/+16
|
* Enter the long awaited start of FreeBSD 6.0!obrien2004-08-211-1/+1
|
* Update for GCC 3.4.2. Bump __FreeBSD_cc_version_ and use correct ELFkan2004-07-281-7/+12
| | | | interpreter on FreeBSD 5.x series.
* Make gcc -pthread link to -lpthread instead of -lc_r.deischen2004-01-301-2/+2
|
* Remove a comment stating that -pthread isn't supported.deischen2003-11-101-11/+9
|
* The ports freeze may take longer than anticipated. Instead ofdeischen2003-09-211-3/+2
| | | | | | | | waiting for it to be delayed, temporarily back out the -pthread removal until the freeze is lifted. Freeze possibly taking longer than necessary: will Requested by: kris
* Bump __FreeBSD_cc_version for (1) 5.1 (post-mortem) (2) -pthread changes.obrien2003-09-121-1/+1
|
* Remove the -pthread option (in FreeBSD versions 500016 and greater) asdeischen2003-09-031-11/+14
| | | | | | | | | | | | | | | | | | threatened over 2 years ago. Why? -pthread was a hack to prevent linking to both libc and libc_r and became unecessary when libc_r became free of libc. Now that we have multiple thread libraries from which to choose, it is more confusing because you can't link to more than one threads library at a time. Things like autoconf and libtool sometimes detect -pthread and also -lc_r, and in conjunction with ports usage of ${PTHREAD_LIBS}, really wacky things ensue when PTHREAD_LIBS is set to another threads library. This might not be so bad if the build broke when this happens, but it doesn't and you don't know it until funny things happen when you run the application (or use an affected library). Reviewed by: obrien
* Backout rev 1.10.deischen2003-09-011-2/+38
| | | | Requested by: obrien
* Remove -pthread as a compiler option. It was deprecated 2.5 yearsdeischen2003-08-311-38/+2
| | | | | | ago, but not removed. No reply from: threads, kan, obrien
* Reformat FBSD_{START,END}FILE_SPEC to FSF coding standards.obrien2003-08-241-19/+24
| | | | Use these in our i386, amd64, and alpha platforms.
* Update for GCC 3.3.1-prerelease.kan2003-07-111-38/+36
|
* Add spaces around FBSD_ENDFILE_SPEC as it is used in string concatenation.obrien2002-12-031-1/+1
| | | | Approved by: re(bmah)
* Remove our custom mixed ELF/a.out support. This means the base compilerobrien2002-11-261-4/+1
| | | | | | | | now only produce ELF objects. It also makes us closer to stock GCC, and simplifies the set of changes we still need from stock GCC on every import. Applauded by: peter Approved by: re
* Remove some debugging cruft I accidently committed with rev 1.4.obrien2002-09-121-7/+0
|
* Try to detect support for the `long long' type so that ANSI-C[89] cleanobrien2002-09-121-1/+14
| | | | | | | | | | | code will know not to try to use `long long'. Unfortunately the GCC spec parser will not allow us to properly detect the "iso9899:1990" and "iso9899:199409" forms of the acceptable -std= arguments, because of the ':' in the -std argument. :-( I have left them in the spec as a place holder in hopes someone knows a way to make the detection of them work. Desired by: wollman
* Bump __FreeBSD_cc_version for gcc 3.1-prerelease -> 3.2.1-snap upgrade.obrien2002-09-091-1/+1
|
* Add tweaks needed when using as the system compiler.obrien2002-05-101-1/+21
|
* Enlist the FreeBSD-CURRENT users as testers of what is to become Gcc 3.1.0.obrien2002-02-011-0/+149
These bits are taken from the FSF anoncvs repo on 1-Feb-2002 08:20 PST.
OpenPOWER on IntegriCloud