| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
GCC 4.2.1 was disconnected from FreeBSD in r358454.
Sponsored by: The FreeBSD Foundation
Notes:
svn path=/head/; revision=358459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Block objects [1] are a C-level syntactic and runtime feature. They
are similar to standard C functions, but in addition to executable
code they may also contain variable bindings to automatic (stack)
or managed (heap) memory. A block can therefore maintain a set of
state (data) that it can use to impact behavior when executed.
This port is based on Apple's GCC 5646 with some bugfixes from
Apple GCC 5666.3. It has some small differences with the support
in clang, which remains the recommended compiler.
Perhaps the most notable difference is that in GCC that __block
is not actually a keyword, but a macro. There will be workaround
for this issue in a near future. Other issues can be consulted in
the clang documentation [2]
For better compatiblity with Apple's GCC and llvm-gcc some related
fixes and features from Apple have been included. Support for the
non-standard nested functions in GCC is now off by default.
No effort was made to update the ObjC support since FreeBSD doesn't
carry ObjC in the base system, but some of the code crept in and
was more difficult to remove than to adjust.
Reference:
[1]
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html
[2]
http://clang.llvm.org/compatibility.html#block-variable-initialization
Obtained from: Apple GCC 4.2
MFC after: 3 weeks
Notes:
svn path=/head/; revision=260311
|
| |
|
|
|
|
|
| |
Approved by: philip (mentor)
Notes:
svn path=/head/; revision=222207
|
| |
|
|
|
|
|
| |
Approved by: re (kensmith)
Notes:
svn path=/head/; revision=171836
|
| |
|
|
| |
Notes:
svn path=/head/; revision=169702
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
understand that non-local variables can never be collected, and when
it collected the static variable for mexitcount_libfunc, gcc aborted
on the next use of this variable.
This quick fix is to reinitialize the variable on every use and depend
on garbage collection recovering the small amount of memory wasted by
this, and not worry by the small amount of time wasted by this. It
would be better to initialize the variable together with most of the
other libfuncs in optabs.c and depend on whatever magic is there to
prevent its collection, but we initialize it here to avoid taking at
least 2 more files off the vendor branch.
Notes:
svn path=/head/; revision=163679
|
| |
|
|
| |
Notes:
svn path=/head/; revision=146908
|
| |
|
|
|
|
|
| |
1.19 Fix -mprofiler-epilogue on i386.
Notes:
svn path=/head/; revision=132732
|
| |
|
|
|
|
|
| |
use TARGET_PROFILER_EPILOGUE if it is defined.
Notes:
svn path=/head/; revision=124167
|
| |
|
|
|
|
|
|
|
| |
architectures in future.
Submitted by: bde
Notes:
svn path=/head/; revision=124160
|
| |
|
|
| |
Notes:
svn path=/head/; revision=122190
|
| |
|
|
| |
Notes:
svn path=/head/; revision=117404
|
| |
|
|
| |
Notes:
svn path=/head/; revision=110621
|
| |
|
|
| |
Notes:
svn path=/head/; revision=107605
|
| |
|
|
| |
Notes:
svn path=/head/; revision=107604
|
| |
|
|
|
|
|
|
|
|
|
| |
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
Notes:
svn path=/head/; revision=107286
|
| |
|
|
|
|
|
|
|
| |
1.2 a.out support
Approved by: obrien
Notes:
svn path=/head/; revision=102794
|
| |
|
|
| |
Notes:
svn path=/head/; revision=96283
|
| |
|
|
| |
Notes:
svn path=/head/; revision=90091
|
| |
|
|
| |
Notes:
svn path=/head/; revision=72564
|
| |
|
|
| |
Notes:
svn path=/head/; revision=70639
|
| |
|
|
| |
Notes:
svn path=/head/; revision=60970
|
| |
|
|
| |
Notes:
svn path=/head/; revision=52763
|
| |
|
|
| |
Notes:
svn path=/head/; revision=52518
|
| |
|
|
| |
Notes:
svn path=/head/; revision=52272
|
| |
|
|
| |
Notes:
svn path=/head/; revision=52268
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a.out gas and the binutils gas (elf or a.out) with a single compiler.
This uses other infrastructure not yet committed, in order to support
both a.out and elf it needs to be able to get to both a.out and elf
gas, ld, libs, crt* etc. So for now, the support is pretty much dormant.
The new freebsd.h file is based on the old freebsd-elf.h file (which has a
long lineage, right back through linux and svr4 files). The change is
pretty dramatic from a gcc internals standpoint as it overrides a lot of
definitions in order to generate different output based on target mode.
There is potential for screw-ups, so please be on the lookout - gcc's
configuration mechanism wasn't really meant for this kind of thing.
It's believed to compile world etc just fine under both a.out and elf, can
handle global constructors and destructors, handles the differences in
a.out and elf stabs, and what sections things like exceptions go in.
The initial idea came from i386/osfrose.h which is a dual rose/elf format
target. These two are not as diverse as a.out and elf it would seem.
The cc front-end uses external configuration to determine default object
format (still being thrashed out, so read the source if you want to see
it so far), and has a '-aout' and '-elf' override command line switch.
There are some other internal switches that can be accessed, namely -maout,
-mno-aout, -munderscores and -mnounderscores. The underscore and local
symbol prefixing rules are controllable seperately to the output format.
(ie: it's possible to generate a.out without the _ prefixes on symbols and
also to generate elf with the _ prefixes. This isn't quite optimal, but
does seem to work pretty well, except the linkers don't always recognise
the local symbols without their normal names)
The default format is a.out (still), nobody should see any major changes.
With both elf and a.out tools and libraries installed:
[1:26pm]/tmp-223> cc -elf -o hello hello.c
peter@beast[1:27pm]/tmp-224> file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
[1:27pm]/tmp-225> ./hello
hello world!
[1:27pm]/tmp-226> cc -aout -o hello hello.c
[1:27pm]/tmp-227> file hello
hello: FreeBSD/i386 compact demand paged dynamically linked executable not stripped
1:27pm]/tmp-228> ./hello
hello world!
Since my co-conspirators put a lot of effort into this too, I'll add them
so they can share the blame^H^H^H^H^Hglory. :-)
Reviewed by: sos, jdp
Notes:
svn path=/head/; revision=34229
|
|
|
non-i386, non-unix, and generatable files have been trimmed, but can easily
be added in later if needed.
gcc-2.7.2.1 will follow shortly, it's a very small delta to this and it's
handy to have both available for reference for such little cost.
The freebsd-specific changes will then be committed, and once the dust has
settled, the bmakefiles will be committed to use this code.
Notes:
svn path=/vendor/gcc/dist/; revision=18334
|
