| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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: 61715
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
just be removed. However, this fixes PR3281:crash04.ll, diagnosing it with:
lvm-as: crash04.ll:2:13: vfcmp requires vector floating point operands
vfcmp uno double* undef, undef
^
llvm-svn: 61680
|
|
|
|
|
|
|
|
| |
llvm-as: crash02.ll:1:62: invalid function return type
declare { <{ <{}>, void ([1898 x { void ()* }], opaque, ...) (), fp128 * }>, opaque } @t ()
^
llvm-svn: 61679
|
|
|
|
|
|
|
|
| |
llvm-as: crash01.ll:1:9: invalid function return type
declare opaque @t()
^
llvm-svn: 61678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnose attempts to initialize non-empty arrays with them. This
produces:
llvm-as: accepted02.ll:1:28: invalid empty array initializer
@"o" = global [5 x double] []
^
llvm-as: accepted00.ll:1:32: invalid empty array initializer
@"za" = thread_local global {} []
^
[
llvm-svn: 61676
|
|
|
|
|
|
|
| |
@t = global i8 0, align 3
^
llvm-svn: 61675
|
|
|
|
|
|
|
| |
ParseAssemblyString with a specified module would not parse
into the module, it would create and return a new one.
llvm-svn: 61635
|
|
|
|
| |
llvm-svn: 61595
|
|
|
|
| |
llvm-svn: 61594
|
|
|
|
| |
llvm-svn: 61585
|
|
|
|
| |
llvm-svn: 61584
|
|
|
|
| |
llvm-svn: 61566
|
|
|
|
| |
llvm-svn: 61564
|
|
|
|
| |
llvm-svn: 61563
|
|
|
|
| |
llvm-svn: 61561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and clean recursive descent parser.
This change has a couple of ramifications:
1. The parser code is about 400 lines shorter (in what we maintain, not
including what is autogenerated).
2. The code should be significantly faster than the old code because we
don't have to work around bison's poor handling of datatypes with
ctors/dtors. This also makes the code much more resistant to memory
leaks.
3. We now get caret diagnostics from the .ll parser, woo.
4. The actual diagnostics emited from the parser are completely different
so a bunch of testcases had to be updated.
5. I now disallow "%ty = type opaque %ty = type i32". There was no good
reason to support this, it was just an accident of the old
implementation. I have no reason to think that anyone is actually using
this.
6. The syntax for sticking a global variable has changed to make it
unambiguous. I don't think anyone is depending on this since only clang
supports this and it is not solid yet, so I'm not worried about anything
breaking.
7. This gets rid of the last use of bison, and along with it the .cvs files.
I'll prune this from the makefiles as a subsequent commit.
There are a few minor cleanups that can be done after this commit (suggestions
welcome!) but this passes dejagnu testing and is ready for its time in the
limelight.
llvm-svn: 61558
|
|
|
|
| |
llvm-svn: 61241
|
|
|
|
| |
llvm-svn: 61240
|
|
|
|
| |
llvm-svn: 61150
|
|
|
|
|
|
| |
builds.
llvm-svn: 61094
|
|
|
|
| |
llvm-svn: 61031
|
|
|
|
|
|
|
|
|
|
| |
alignment attribute such that 0 means unaligned.
This will probably require a rebuild of llvm-gcc because of the change to
Attributes.h. If you see many test failures on "make check", please rebuild
your llvm-gcc.
llvm-svn: 61030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
callee will not introduce any new aliases of that pointer.
The attributes had all bits allocated already, so I decided to collapse
alignment. Alignment was previously stored as a 16-bit integer from bits 16 to
32 of the attribute, but it was required to be a power of 2. Now it's stored in
log2 encoded form in five bits from 16 to 21. That gives us 11 more bits of
space.
You may have already noticed that you only need four bits to encode a 16-bit
power of two, so why five bits? Because the AsmParser accepted 32-bit
alignments, even though we couldn't store them (they were silently discarded).
Now we can store them in memory, but not in the bitcode.
The bitcode format was already storing these as 64-bit VBR integers. So, the
bitcode format stays the same, keeping the alignment values stored as 16 bit
raw values. There's some hideous code in the reader and writer that deals with
this, waiting to be ripped out the moment we run out of bits again and have to
replace the parameter attributes table encoding.
llvm-svn: 61019
|
|
|
|
|
|
|
|
|
| |
indicate functions that allocate, such as operator new, or list::insert. The
actual definition is slightly less strict (for now).
No changes to the bitcode reader/writer, asm printer or verifier were needed.
llvm-svn: 59934
|
|
|
|
| |
llvm-svn: 59204
|
|
|
|
| |
llvm-svn: 59202
|
|
|
|
| |
llvm-svn: 58697
|
|
|
|
| |
llvm-svn: 58696
|
|
|
|
| |
llvm-svn: 58694
|
|
|
|
| |
llvm-svn: 58693
|
|
|
|
|
|
| |
llvmAsmParser.h.
llvm-svn: 58130
|
|
|
|
|
|
| |
the pregenerated file in from the svn (.cvs). Work only for windows for the moment. Tested on Vista64 with MSVC2008express.
llvm-svn: 58090
|
|
|
|
| |
llvm-svn: 57577
|
|
|
|
| |
llvm-svn: 57576
|
|
|
|
| |
llvm-svn: 57575
|
|
|
|
| |
llvm-svn: 57574
|
|
|
|
| |
llvm-svn: 57573
|
|
|
|
| |
llvm-svn: 57572
|
|
|
|
| |
llvm-svn: 57561
|
|
|
|
|
|
|
| |
integer type. Invalid things like 'float 42' are now rejected by the
semantic analysis in the productions not the parser. This fixes PR2733.
llvm-svn: 57560
|
|
|
|
| |
llvm-svn: 57559
|
|
|
|
|
|
| |
INTTYPE everywhere.
llvm-svn: 57558
|