| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 61744
|
| |
|
|
| |
llvm-svn: 61743
|
| |
|
|
|
|
|
|
| |
In fact this also deletes those with linkonce linkage,
however this is currently dead because for the moment
aliases aren't allowed to have this linkage type.
llvm-svn: 61742
|
| |
|
|
| |
llvm-svn: 61741
|
| |
|
|
|
|
| |
in its hand.
llvm-svn: 61740
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Entry point is tools/ccc/xcc until we are a functional replacement
for ccc.
This is highly experimental (FIXME/LOC ratio of 3.4%), quite crufty,
and barely usable (and then only on my specific Darwin). However, many
of the right ideas are present, and it already fixes a number of
things gcc gets wrong.
The major missing component is argument translation for tools
(translating driver arguments into cc1/ld/as/etc. arguments). This is
a large part of the driver functionality and will probably double the
LOC, but my hope is that the current architecture is relatively
stable.
Documentation & motivation to follow soon...
llvm-svn: 61739
|
| |
|
|
| |
llvm-svn: 61737
|
| |
|
|
|
|
| |
build errors.
llvm-svn: 61736
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.
Only enumerations and linkage specifications currently use transparent
DeclContexts.
Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.
llvm-svn: 61735
|
| |
|
|
|
|
| |
their length.
llvm-svn: 61734
|
| |
|
|
|
|
|
| |
own OpActionsCapacity magic number; it can just use ISD::BUILTIN_OP_END,
as long as it takes care to round up when needed.
llvm-svn: 61733
|
| |
|
|
| |
llvm-svn: 61732
|
| |
|
|
| |
llvm-svn: 61731
|
| |
|
|
|
|
|
| |
not in system library directories by checking -L paths as well.
Patch by Axel Naumann!
llvm-svn: 61730
|
| |
|
|
| |
llvm-svn: 61729
|
| |
|
|
| |
llvm-svn: 61728
|
| |
|
|
| |
llvm-svn: 61727
|
| |
|
|
| |
llvm-svn: 61726
|
| |
|
|
|
|
|
|
| |
llvm-as: accepted03.ll:1:35: invalid unresolved type up reference
declare void @r({ \7, opaque, \10 } %su)
^
llvm-svn: 61725
|
| |
|
|
| |
llvm-svn: 61724
|
| |
|
|
|
|
| |
problem, rather than fixing it. The problem has now been fixed the right way.
llvm-svn: 61723
|
| |
|
|
|
|
|
|
| |
llvm-as: crash11.ll:2:27: function may not return return opaque type
"xw" = tail call opaque @608(label %31)
^
llvm-svn: 61722
|
| |
|
|
|
|
|
| |
llvm-as: crash10.ll:3:35: floating point constant does not have type 'ppc_fp128'
"dumy" = fcmp ult ppc_fp128 "j",9209.4
^
llvm-svn: 61721
|
| |
|
|
|
|
|
|
| |
llvm-as: crash09.ll:3:1: self referential type is invalid
type %0
^
llvm-svn: 61720
|
| |
|
|
|
|
| |
test/Assembler/2005-05-05-OpaqueUndefValues.ll
llvm-svn: 61719
|
| |
|
|
| |
llvm-svn: 61718
|
| |
|
|
| |
llvm-svn: 61715
|
| |
|
|
| |
llvm-svn: 61714
|
| |
|
|
| |
llvm-svn: 61713
|
| |
|
|
| |
llvm-svn: 61711
|
| |
|
|
| |
llvm-svn: 61710
|
| |
|
|
| |
llvm-svn: 61709
|
| |
|
|
|
|
| |
conventions, per John Criswell.
llvm-svn: 61708
|
| |
|
|
| |
llvm-svn: 61707
|
| |
|
|
|
|
|
|
|
|
| |
- After GlobalAssign, emit addrspace before global/constant, to follow
the new syntax.
- Eliminate "type void", which is now invalid.
- Fix invalid liblists like [, "foo"].
- Tweak whitespace in a few places.
llvm-svn: 61706
|
| |
|
|
| |
llvm-svn: 61703
|
| |
|
|
| |
llvm-svn: 61702
|
| |
|
|
|
|
|
| |
* some picky <g> compilers get insulted by const-incorrectness
* respect 80-char limit
llvm-svn: 61701
|
| |
|
|
| |
llvm-svn: 61700
|
| |
|
|
| |
llvm-svn: 61699
|
| |
|
|
| |
llvm-svn: 61695
|
| |
|
|
|
|
|
|
|
| |
This means that we have to include an additional header.
This patch should be functionally equivalent. I cannot outrule any performance
degradation, though I do not expect any.
llvm-svn: 61694
|
| |
|
|
|
|
| |
fails, like it is right now.
llvm-svn: 61690
|
| |
|
|
| |
llvm-svn: 61688
|
| |
|
|
| |
llvm-svn: 61686
|
| |
|
|
| |
llvm-svn: 61685
|
| |
|
|
|
|
|
|
| |
llvm-as: crash08.ll:3:15: invalid operand type for instruction
"qp" = sdiv fp128 0x1, %30
^
llvm-svn: 61684
|
| |
|
|
|
|
|
| |
llvm-as: crash07.ll:2:32: va_arg requires operand with first class type
%y = va_arg [52 x <{}>] %43, double (...) sspreq
^
llvm-svn: 61683
|
| |
|
|
| |
llvm-svn: 61682
|
| |
|
|
|
|
|
|
|
|
|
|
| |
diagnostics:
llvm-as: crash05.ll:1:14: invalid type for null constant
global label zeroinitializer addrspace (75), section "c"
^
llvm-as: crash06.ll:2:14: invalid type for null constant
udiv label zeroinitializer, @0
^
llvm-svn: 61681
|