| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 129467
|
| |
|
|
|
|
|
| |
ignored. There was a test to catch this, but it was just blindly updated in
a large change. This fixes another part of <rdar://problem/9275290>.
llvm-svn: 129466
|
| |
|
|
|
|
| |
defined in a macro. // rdar://9091893
llvm-svn: 129465
|
| |
|
|
|
|
| |
generated by a regular 'load' now.
llvm-svn: 129464
|
| |
|
|
| |
llvm-svn: 129463
|
| |
|
|
|
|
|
|
| |
as such.
rdar://problem/9276651
llvm-svn: 129462
|
| |
|
|
|
|
| |
understand actual reason behind this fixme. Spot checking suggest that newer gdb does not need this.
llvm-svn: 129461
|
| |
|
|
|
|
| |
llvm-gcc-native-mingw32 builder.
llvm-svn: 129457
|
| |
|
|
|
|
|
|
| |
not properly handled.
rdar://problem/9276427
llvm-svn: 129456
|
| |
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=129387.
llvm-svn: 129451
|
| |
|
|
| |
llvm-svn: 129450
|
| |
|
|
|
|
|
|
|
| |
LoopUnroll class's ctor. Doing so
will allow multiple context with different loop unroll parameters to run. This is a minor change and no effect
on existing application.
llvm-svn: 129449
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relocations between the object modules are properly resolved, as in the
following trivial example:
$ cat t.c
int foo();
int main() {
return foo();
}
$ cat foo.c
int foo() {
return 65;
}
$ clang -c t.c -fno-asynchronous-unwind-tables
$ clang -c foo.c -fno-asynchronous-unwind-tables
$ llvm-rtdyld t.o foo.o ; echo $?
loaded '_main' at: 0x10015c000
65
llvm-svn: 129448
|
| |
|
|
| |
llvm-svn: 129447
|
| |
|
|
| |
llvm-svn: 129446
|
| |
|
|
| |
llvm-svn: 129445
|
| |
|
|
|
|
|
|
|
| |
component names such as "engine" do not expand to "jit" and hence to
the native target libraries for external users.
Thanks to arrowdodger for reporting and diagnosing the problem.
llvm-svn: 129444
|
| |
|
|
|
|
| |
related tweaks to ExprMapKeyType.
llvm-svn: 129443
|
| |
|
|
| |
llvm-svn: 129442
|
| |
|
|
| |
llvm-svn: 129441
|
| |
|
|
| |
llvm-svn: 129440
|
| |
|
|
| |
llvm-svn: 129439
|
| |
|
|
|
|
| |
even if an identifier could resolve to a builtin.
llvm-svn: 129438
|
| |
|
|
| |
llvm-svn: 129437
|
| |
|
|
| |
llvm-svn: 129436
|
| |
|
|
| |
llvm-svn: 129435
|
| |
|
|
| |
llvm-svn: 129434
|
| |
|
|
| |
llvm-svn: 129433
|
| |
|
|
|
|
|
| |
the max itself, so it is not easy to write a test case for this, but I added a
test case that would fail if the code in AsmPrinter were removed.
llvm-svn: 129432
|
| |
|
|
|
|
|
|
|
|
|
| |
evaluated and unevaluated contexts. Add some testing of sizeof and
typeid.
Both of the typeid tests added here were triggering warnings previously.
Now the one false positive is suppressed without suppressing the warning
on actually buggy code.
llvm-svn: 129431
|
| |
|
|
|
|
| |
RewriterOptions struct.
llvm-svn: 129430
|
| |
|
|
| |
llvm-svn: 129429
|
| |
|
|
|
|
|
| |
alignment for its type, use the minimum of the specified alignment and the ABI
alignment. This fixes <rdar://problem/9275290>.
llvm-svn: 129428
|
| |
|
|
|
|
|
|
|
| |
take it!
I wasn't able to get __builtin_ia32_loaddqu to transform into an unaligned
load...I'll have to look into it further.
llvm-svn: 129427
|
| |
|
|
| |
llvm-svn: 129426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the type of one of the base classes then downgrade the missing typename error to a warning. Up to now this is the only case I found where MSVC doesn't require "typename" at class scope. Really strange!
This fixes 1 error when parsing the MSVC 2008 header files.
Example:
template<class T> class A {
public:
typedef int TYPE;
};
template<class T> class B : public A<T> {
public:
A<T>::TYPE a; // no typename required because A<T> is a base class.
};
llvm-svn: 129425
|
| |
|
|
| |
llvm-svn: 129424
|
| |
|
|
| |
llvm-svn: 129423
|
| |
|
|
| |
llvm-svn: 129422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latency.
Additional fixes:
Do something reasonable for subtargets with generic
itineraries by handle node latency the same as for an empty
itinerary. Now nodes default to unit latency unless an itinerary
explicitly specifies a zero cycle stage or it is a TokenFactor chain.
Original fixes:
UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make the ndoe latency adjustments work, I also
needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.
llvm-svn: 129421
|
| |
|
|
| |
llvm-svn: 129420
|
| |
|
|
| |
llvm-svn: 129419
|
| |
|
|
| |
llvm-svn: 129417
|
| |
|
|
|
|
| |
versions.
llvm-svn: 129416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lldb_private::OptionGroup
lldb_private::OptionGroupOptions
OptionGroup lets you define a class that encapsulates settings that you want
to reuse in multiple commands. It contains only the option definitions and the
ability to set the option values, but it doesn't directly interface with the
lldb_private::Options class that is the front end to all of the CommandObject
option parsing. For that the OptionGroupOptions class can be used. It aggregates
one or more OptionGroup objects and directs the option setting to the
appropriate OptionGroup class. For an example of this, take a look at the
CommandObjectFile and how it uses its "m_option_group" object shown below
to be able to set values in both the FileOptionGroup and PlatformOptionGroup
classes. The members used in CommandObjectFile are:
OptionGroupOptions m_option_group;
FileOptionGroup m_file_options;
PlatformOptionGroup m_platform_options;
Then in the constructor for CommandObjectFile you can combine the option
settings. The code below shows a simplified version of the constructor:
CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) :
CommandObject (...),
m_option_group (interpreter),
m_file_options (),
m_platform_options(true)
{
m_option_group.Append (&m_file_options);
m_option_group.Append (&m_platform_options);
m_option_group.Finalize();
}
We append the m_file_options and then the m_platform_options and then tell
the option group the finalize the results. This allows the m_option_group to
become the organizer of our prefs and after option parsing we end up with
valid preference settings in both the m_file_options and m_platform_options
objects. This also allows any other commands to use the FileOptionGroup and
PlatformOptionGroup classes to implement options for their commands.
Renamed:
virtual void Options::ResetOptionValues();
to:
virtual void Options::OptionParsingStarting();
And implemented a new callback named:
virtual Error Options::OptionParsingFinished();
This allows Options subclasses to verify that the options all go together
after all of the options have been specified and gives the chance for the
command object to return an error. It also gives a chance to take all of the
option values and produce or initialize objects after all options have
completed parsing.
Modfied:
virtual Error
SetOptionValue (int option_idx, const char *option_arg) = 0;
to be:
virtual Error
SetOptionValue (uint32_t option_idx, const char *option_arg) = 0;
(option_idx is now unsigned).
llvm-svn: 129415
|
| |
|
|
|
|
| |
undergoes preprocessing.
llvm-svn: 129414
|
| |
|
|
|
|
| |
Implement the ones that were missing in the asm streamer.
llvm-svn: 129413
|
| |
|
|
|
|
|
| |
objective-c instead of crashing in IRgen.
// rdar://9154582.
llvm-svn: 129412
|
| |
|
|
|
|
| |
rdar://problem/9273947
llvm-svn: 129411
|
| |
|
|
|
|
|
|
|
|
| |
there is no reason to align them higher.
- This roughly matches llvm-gcc's r126913.
- It is an open question whether or not we should do this for cstring's in
general (code size vs optimization potential), for now we just match llvm-gcc
until someone wants to run some experiments.
llvm-svn: 129410
|