| Age | Commit message (Collapse) | Author |
|---|
|
While these versions of gcc don't have full C99 support, it is
better than defaulting to C89 when building modern software.
OK deraadt@
|
|
There has been some unexpected fallout. Requested by deraadt@.
|
|
While these versions of gcc don't have full C99 support, it is
better than defaulting to C89 when building modern software.
OK deraadt@
|
|
ok miod
|
|
In c99 any value can be initalised using a { 0 } constructor independent
of the type. Now if a struct's first member is another struct then gcc4
issues the above warning but it should not do that.
Move the warning check from push_init_level() to pop_init_level() and
check if either { 0 } or { } was used. If additional implicit braces
were added surpress the warning.
Inspired by gcc PR#64709
OK deraadt@ miod@
|
|
allow execute-only binaries
ok miod
|
|
with --execute-only in the linker
ok kettenis
|
|
architecture by changing JUMP_TABLES_DEFAULT
ok kettenis
|
|
trying to read a branch instruction and decode it to extract the address
of the ld.so resolver function. Instead, directly execute that branch
instruction.
This is effectively a C runtime ABI change. In order to cross this if
you are building from source, make sure you install an updated ld.so
first.
ok deraadt@
|
|
to produce 99+% correct code at all optimization levels, and can help people
who would like to tinker a bit with the backend.
(note m88k ports still use gcc 3 at the moment)
|
|
base-gcc always errored out when -Werror was passed and -Wuninitialized
triggered, even when -Wno-error=uninitialized was passed.
Deemed correct by Miod
|
|
We are never updating this sub-tree. Knock out the collision in the simplest
way. diff from mortimer.
This is the last change required for -fno-common on all architectures,
thanks to mortimer for starting the effort and encouraging others.
|
|
Fixes creation of static binaries with base gcc and ld.lld.
OK kettenis@ a while ago, prodded by daniel@
|
|
Appending "%n" to the format string to capture the output-length in bytes
(into an uninitialized variable) is exactly the same as using the printf
return value. Why did they do this so unnaturally?
(normally we don't change gcc import code, but I'm doing a study of %n
prevelance)
ok millert
|
|
I don't know much about compilers, but what I do have are a very particular
set of skills. Skills I have acquired over a very long career.
|
|
does not have a default search path. ok kettenis@ jsg@
|
|
flatly.
this will help sparc64 compile code without needing to patch away recent
pragma diagnostic use.
problem found by landry@
okay kettenis@, guenther@
|
|
as the default linker on armv7.
ok espie@
|
|
This allows linking code compiled by clang with the gcc compiler driver
and makes sure we always use the softfloat implementation in libc. The
libc softfloat implementation is preferred over the one in libgcc as it
implements rounding modes and floating point exceptions.
ok patrick@
|
|
as full memory barriers.
|
|
With clang -Os doesn't generate the smallest code possible but some middle
ground between optimization for speed and optimization for size. A new -Oz
option was introduced for optmization for size only. We need that for our
floppies, otherwise they overflow. Making gcc accept -Oz too makes our life
easier.
ok millert@, deraadt@, robert@
|
|
For C++, gcc has to make use of comdat sections instead
of .gnu.linkonce sections for this because
switch tables and functions would now end up
in different .gnu.linkonce sections. This can cause ld
to sometimes incorrectly discard the switch tables, which causes
linker errors. With comdat sections, making the switch table
and function sections belong together is more reliable.
ok deraadt@
|
|
Reimplement that from scratch in our ancient gcc, because it's really
useful for porting newer code and dealing with compiler variations.
(slightly tweaked to reset location to unknown location after the okays)
okay kettenis@ jasper@
found out https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
after the patch, which explains a similar reasoning better, and leads
to another patch for older GCC, possibly GPLv3.
|
|
i got sick of not having arguments in ddb stack traces on amd64,
which is because amd64 passes arguments in registers, and it's
impossible to figure out where they go without dwarf info, and when
you have dwarf info it is complicated.
solaris has a simple solution for this. they tweaked their compilers
to accept an -msave-args option which makes functions store their
arguments on the stack, while maintaining compatability with the
System V AMD64 ABI. tools (eg, ddb) can then look at the stack to
get access to function arguments in traces.
this ports their changes to gcc 3 to our gcc.
ok deraadt@
|
|
ok krw@
|
|
the expectations of the DWARF code... and in order to get correct information.
Tested by aoyama@
|
|
true reason of objc still being in-tree is to expose compiler issues.
|
|
The same change was made in ports gcc 4.9 already. This is is most
recent arm architecture version base gcc has support for.
This changes builtin defines from __ARM_ARCH_5TE__ to __ARM_ARCH_6K__.
These defines are often used to select between inline assembly paths.
Note that base gcc still lacks support for atomic builtins available
in ports gcc and clang however.
ok patrick@ kettenis@
|
|
as any of the stack or frame pointers are modified.
Allow narrower-than-register types to be kept in registers in wider modes,
as was the case with gcc 3.
This now seems to produce reliable code with -O1. -O2 is not safe yet.
|
|
|
|
variable or parameter is a pointer to a function.
ok kettenis@
|
|
ok guenther@, jsg@
|
|
libsupc++. Passes the (limited) tests in the gcc 4.2.1 testsuite.
ok patrick@, tom@
|
|
break which cannot be easily crossed.
ok kettenis@ jsg@
|
|
Adapted from a change to mainline gcc while it was still GPLv2.
Original diff found by stefan@
Adaptation by me
ICE caught by ml(at)extensibl(dot)com while he was porting MLton
to OpenBSD.
Ok stefan@
"Go for it" deraadt@
|
|
C11 feature that is starting to get used in places such as Mesa.
This implementation takes a different approach to upstream and is therefore
not covered by GPLv3.
ok stefan@, jsg@
|
|
From Miod Vallat
I trust miod deraadt@
|
|
arm9e (armv5te w/o xscale extensions). We no longer support anything
less than armv5te and this allows some additional instructions.
-mthumb-interwork remains off by default.
ok patrick@
|
|
into a register. Fixes an ICE when building Mesa with __sync builtins.
From Roger Sayle in gcc svn rev 121779 in Feb 2007 before the license
change.
Tested by miod and matthieu.
|
|
this can happen due to the frame layout change introduced in order to
support the stack protector. Fix from miod.
Bug originally observed by jca and condensed to a 3-liner by myself,
basically local [] arrays being initialized with shorter strings.
|
|
from Jan Schreiber, ok deraadt@
|
|
|
|
Help with testing and ok kettenis@
|
|
emit a "sync" instruction.
ok visa@
|
|
In some cases GCC would generate a cmpxchg8b instruction with a memory
reference that used %ebx. This is wrong (and will almost certainly result
in SIGSEGV). This fix uses a new memory constraint "W" to prevent the use
of %ebx in this case. This differs from the approach taken by upstream so
there are no GPLv3 issues here.
Fixes the Mesa i965 dri module on i386.
ok jsg@
|
|
NOTE: cc1 uses brk/sbrk, which was only enabled in pledge a few hours
ago. So this requires a fairly new kernel if compiling monster c++
programs..
|
|
(cc1 "toplev.c" uses brk/sbrk, so it is on hold to figure out the right
direction...)
ok semarie pascal
|
|
kettenis ok'd me poking around in here; ingo ok'd the diff
|
|
gcc and g++ can currently have different ideas on the size of a
packed enum type:
enum __attribute__((packed)) foo { a = 0, b};
gcc: 1
g++: 4
enum foo { a = 0, b} __attribute__((packed));
gcc: 1
g++: 1
The first format is actually the preferred one according to the
documentation.
https://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Type-Attributes.html
g++ will accept the first format and silently not actually choose a
smaller size.
This was responsible for memory corruption with recent versions
of Mesa where c and c++ code share a header with a packed enum type.
The problem was reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
and fixed in gcc >= 4.3.6 in rev 144284.
This was after the switch from gplv2 but it's a trivial one line change.
ok guenther@ deraadt@ kettenis@
|
|
This symbol isn't used anywhere outside libstdc++, thus no bump.
Upstream initially went the samy way, but then implemented a different fix,
which don't work for us. Eventually we should move to whitelisting the list
of symbols exported anyway.
okay miod@, no objections from sthen@; also supported by a few a while ago
|
