Hi,
So in a personal communication, James has pointed out that there are
some subtle differences between C and C++ specifications.
What's the semantics for OpenCL++ to be? Is it basically version of
C++ plus whatever modifications langOpts.openCL adds to clang (ie, in
case of divergence between
The patch LGTM.
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu
[mailto:cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Pedro Ferreira
Sent: 13 May 2014 10:03
To: cfe-commits@cs.uiuc.edu
Subject: [PATCH] Clang: Reject OpenCL workgroup size requirement of 0
OpenCL allows us to
I wonder if, with C++11 named initialization syntax for PODs, something
could be done so that in cases like this a (function specific, I guess)
optional options object could be used. (This would avoid one of the big
problems with C++ optional arguments, which is that if one towards the end
needs
Ah forget that. It's been a while since I tried these games and remember now
why it doesn't work.
-Original Message-
From: cfe-dev-boun...@cs.uiuc.edu [mailto:cfe-dev-boun...@cs.uiuc.edu] On
Behalf Of David Tweed
Sent: 02 May 2014 09:17
To: 'Alp Toker'; cfe-commits@cs.uiuc.edu; clang-dev
Hi,
This looks patch looks LGTM, but being hyper-pedantic I'd suggest
saying in the commit message that it enforces the restriction that a
kernel parameter cannot be declared as a pointer to the private
address space (as clarified in OpenCL 1.2) (since clang isn't really
doing any discrimation of
Author: davidtweed
Date: Thu Mar 27 11:34:11 2014
New Revision: 204941
URL: http://llvm.org/viewvc/llvm-project?rev=204941view=rev
Log:
Enforce the restriction that a parameter to a kernel function
cannot be a pointer to the private address space (as clarified
in the OpenCL 1.2 specification).
No problem: r204941.
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On Behalf Of Fraser Cormack
Sent: 27 March 2014 12:01
To: David Tweed
Cc: llvm cfe
Subject: Re: [PATCH] OpenCL 1.2 disallow kernel parameters with private address
space
So this is an absolutely fine commit, but I guess this does highlight
that, once people get seriously stuck into implementing OpenCL 2.0
(and so we'll acquire the generic address space, to/from which one can
cast pointers in other address spaces) we'll have subtly different
rules for the two
On Tue, Jan 14, 2014 at 3:54 PM, Joey Gouly joey.go...@arm.com wrote:
On 14/01/2014 13:15, David Tweed wrote:
So this is an absolutely fine commit, but I guess this does highlight
that, once people get seriously stuck into implementing OpenCL 2.0
(and so we'll acquire the generic address
Hi,
I personally find the first style much easier to skim/scan -- which is
when this kind of thing matters -- and indeed only write something
like the first if I'm forced to by a language where the computer uses
hanging constructs to detect a continuation line, which isn't the case
for the C++
Hi, this is clearly a useful warning that it would be good to have,
but it probably falls into the same class as assignments in
conditionals: sometimes that is what you intended to do, so is there
some syntactic way that could be used to indicate this is what I
intended in this usage.
In
Hi all,
Added: cfe/trunk/test/SemaOpenCL/invalid-constant.cl
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/invalid-constant.cl?rev=198422view=auto
==
---
Author: davidtweed
Date: Wed Dec 11 07:39:46 2013
New Revision: 197036
URL: http://llvm.org/viewvc/llvm-project?rev=197036view=rev
Log:
Add front-end infrastructure now address space casts are in LLVM IR.
With the introduction of explicit address space casts into LLVM, there's
a need to provide
Further testing (although still very limited because few codebases actually
use address spaces) didn't throw up any problems, so I committed this on
Michele's behalf in 4917036. (I think it's probably appropriate for Michele to
apply for commit rights after several patches which have gone
That's a touch typing error: it's r197036.
http://llvm-reviews.chandlerc.com/D2241
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Some comments from someone who doesn't do much front-end stuff, but overall
looks reasonable to me.
Comment at: lib/CodeGen/CGExprScalar.cpp:1304
@@ +1303,3 @@
+unsigned SrcAS = Src-getType()-getPointerAddressSpace();
+if (Ty-isPtrOrPtrVectorTy()
());
Michele Scandale wrote:
David Tweed wrote:
I'm not very experienced in this part of the codebase: by what paths would
we now end up with a CK_BitCast that's actually an address space cast (that
hasn't be actually generated as an CK_AddressSpaceConversion by the front
end
Having looked at this I believe it's doing the right thing in the OpenCL
cases, and I'd support it going in on those grounds. However, address spaces
are also intended to be usable for security, and I don't have any really
understanding of that area.
Comment at:
Regarding your response, that seems reasonable. I guess it's up to the
address spaces for security guys to validate clang's semantic checking with
respect to their needs. (I'd been thinking about devious things like somehow
creating an one of those pointer types and using it to put the
From my inspection the patch looks good to me.
On Wed, Nov 20, 2013 at 3:11 PM, Anastasia Stulova
anastasia.stul...@arm.com wrote:
Hello,
I would like to submit a patch that fixes the crash in clang at code
generation phase. This problem appears when a store into .hi or .odd of a
vector
Hi,
On Thu, Nov 21, 2013 at 8:54 AM, Pekka Jääskeläinen
pekka.jaaskelai...@tut.fi wrote:
Hi all,
On 11/20/2013 03:54 PM, David Tweed wrote:
Note that in the OpenCL use case, the name precisely describes the intent:
you can move barrier calls around, inline them, etc, if you can show
On Thu, Nov 21, 2013 at 5:30 PM, Tom Stellard t...@stellard.net wrote:
I think we should nominate this patch for the 3.4 branch once it is
committed to ToT.
Just to say explicitly: Joey committed this on Anna's behalf in r19537.
Given that it's a very low risk change that fixes an
On Wed, Nov 20, 2013 at 1:22 PM, Aaron Ballman aa...@aaronballman.comwrote:
On Fri, Nov 15, 2013 at 5:49 AM, Marcello Maggioni
marce...@codeplay.com wrote:
Hi all,
I made a patch that adds the capability of defining the NoDuplicate
attribute for a function using both the GNU and CXX11
Hi Bernie,
* I don't see the coding style violation - what am I missing?
I think James is just referring to not placing the else on the same line as
the previous closing brace in
}
+else if (CPU == cortex-a53 || CPU == cortex-a57) {
Cheers,
Dave
Author: davidtweed
Date: Fri Sep 13 07:04:22 2013
New Revision: 190684
URL: http://llvm.org/viewvc/llvm-project?rev=190684view=rev
Log:
Certain multi-platform languages, such as OpenCL, have the concept of
address spaces which is both (1) a semantic concept and
(2) possibly a hardware level
Committed r190684.
-Original Message-
From: Michele Scandale [mailto:michele.scand...@gmail.com]
Sent: 12 September 2013 14:09
To: David Tweed
Cc: Mon Ping Wang; cfe-...@cs.uiuc.edu; cfe-commits@cs.uiuc.edu; Tanya Lattner;
Eli Friedman
Subject: Re: OpenCL address space and mangling
Author: davidtweed
Date: Fri Sep 13 07:51:05 2013
New Revision: 190687
URL: http://llvm.org/viewvc/llvm-project?rev=190687view=rev
Log:
A buildbot compiling with strict error on unused variables pointed out a
historical remnant in r190684; remove it.
Modified:
-
From: Michele Scandale [mailto:michele.scand...@gmail.com]
Sent: 12 September 2013 12:35
To: David Tweed
Cc: Mon Ping Wang; cfe-...@cs.uiuc.edu; cfe-commits@cs.uiuc.edu; Tanya Lattner;
Eli Friedman
Subject: Re: OpenCL address space and mangling
On 09/11/2013 11:55 AM, David Tweed wrote:
while
Ping Wang
Cc: cfe-...@cs.uiuc.edu; cfe-commits@cs.uiuc.edu; Tanya Lattner; David
Tweed; Eli Friedman
Subject: Re: OpenCL address space and mangling
Reup and updated version of the patch!
Thanks in advance.
Regards,
-Michele
On 09/06/2013 01:48 PM, Michele Scandale wrote:
On 09/06/2013 12:54 PM
Author: davidtweed
Date: Tue Sep 10 03:00:34 2013
New Revision: 190390
URL: http://llvm.org/viewvc/llvm-project?rev=190390view=rev
Log:
Fix minor coding style issue in r190296 pointed out by Richard Smith.
Modified:
cfe/trunk/lib/Basic/TargetInfo.cpp
Modified:
Author: davidtweed
Date: Mon Sep 9 04:17:24 2013
New Revision: 190296
URL: http://llvm.org/viewvc/llvm-project?rev=190296view=rev
Log:
The OpenCL standard specifies the sizes and alignments of various types than
other C-family
languages, as well as specifying errno is not set by the math
Committed (after removing a debugging '#if 1' typo) in 190296. Thanks to Erik
for pushing this forward.
Cheers,
Dave
-Original Message-
From: Erik Schnetter [mailto:schnet...@gmail.com]
Sent: 08 September 2013 19:00
To: Tom Stellard
Cc: Michele Scandale; cfe-commits@cs.uiuc.edu; David
-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On Behalf Of David Tweed
Sent: 09 September 2013 10:17
To: cfe-commits@cs.uiuc.edu
Subject: r190296 - The OpenCL standard specifies the sizes and alignments of
various types than other C-family
Author: davidtweed
Date: Mon Sep 9 04:17
Author: davidtweed
Date: Mon Sep 9 04:55:07 2013
New Revision: 190297
URL: http://llvm.org/viewvc/llvm-project?rev=190297view=rev
Log:
Commit 190296 missed out the tests; add them now. Note that it actually tests
long long which is currently technically only reserved for future use in
OpenCL,
: 'Peter N Lewis'; David Tweed
Subject: RE: [PATCH V2] Allow increment/decrement operators on integer vectors
in OpenCL
Hi Peter David,
This is the latest version patch based on your suggestions. If it is OK, can
anybody help to commit?
Thanks!
Ruiling
-- IMPORTANT NOTICE: The contents
Author: davidtweed
Date: Fri Sep 6 04:58:08 2013
New Revision: 190129
URL: http://llvm.org/viewvc/llvm-project?rev=190129view=rev
Log:
OpenCL allows the (pre/post)-(increment/decrement) operator on integer vector
types,
so allow that case and add appropriate tests.
Patch by Ruiling Song!
...@gmail.com]
Sent: 06 September 2013 11:12
To: Erik Schnetter
Cc: Tom Stellard; cfe-commits@cs.uiuc.edu; David Tweed
Subject: Re: OpenCL C long should always have 64 bits
On 09/04/2013 05:53 PM, Erik Schnetter wrote:
I do not have commit rights. How do I get this patch committed?
-erik
I think
Hi, sorry I must have missed when the first version when it was sent out. It
looks good to me, although I note that your test just happens to have
pre-decrements and post-increments only so it'd probably be good to mix them
around to have all 4 possibilities somewhere.
Cheers,
Dave
From:
Hi,
I've had a look over the patches and they Look Good To Me (assuming the plan is
to get something definite committed within ForcedLangOpts and then refactoring
later if there's a consensus). About the only thing that I noticed was that all
other tests that use a static assert open-code it
Hi, been a bit snowed under so slow responding. It looks like this is a
reasonable proposal that would advance having common OpenCL functionality in
OSS clang rather than re-implemented in individual implementations, certainly
for the kind of issues we've been considering for OpenCL-on-GPU. I
Hi,
| The address space map IMO should not be imposed, because it represents how a
| given OpenCL address space should be mapped to target address space that the
| target backend is able to handle.
I think that the view on how to represent OpenCL address spaces (front-end vs
back-end) has
| The pure solution would be the one proposed by Eli: I don't have any objection
| to this solution.
| The mangler now has a bug, so it must be fixed. The pure solution implicitly
| breaks the binary compatibility. If we do not have problem with this (so we
| consider a matter for the users to
Jääskeläinen [mailto:pekka.jaaskelai...@tut.fi]
Sent: 08 August 2013 10:34
To: cfe-commits@cs.uiuc.edu
Cc: David Tweed; eli.fried...@gmail.com; to...@nondot.org; Chuck Zhao; Kalle
Raiskila
Subject: Re: [PATCH v3] Set some OpenCl specification mandated
types/alignments/etc
Ping?
Here's a direct link
Hi, I haven't been following the formatter patches (partly because it looks
like a big collection of different cases and I don't really have the time to
devote to understanding it) so this is maybe naive or has been done before, but
presumably formatting isn't that performance sensitive so is
Thanks for doing this. This is needed to make the test pass on any 32 bit
target (eg, 32-bit ARM as well as i686).
Cheers
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu
[mailto:cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Nick Lewycky
Sent: 12 February 2013 08:59
To:
Hi,
Out of curiosity is there a description of the cost function that's being
assigned (ie, simplified from the code that actually calculates things)
available anywhere?
Regards,
Dave
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On
| Attached is a patch that checks for variadic macros, bitfields and VLAs;
| which are all unsupported in OpenCL.
| I squished them into one patch, since they are quite small.
The attached patch looks good to me.
Cheers,
Dave
___
cfe-commits
Author: davidtweed
Date: Thu Jan 10 03:11:33 2013
New Revision: 172047
URL: http://llvm.org/viewvc/llvm-project?rev=172047view=rev
Log:
Testing with a full OpenCL compiler (based on clang) reveals r71734 missed
difference between type widths of a vector and the width of one of its elements
in the
vectors from
some hack constructs.
Regards,
Dave
From: Chandler Carruth [mailto:chandl...@google.com]
Sent: 10 January 2013 09:32
To: David Tweed
Cc: llvm cfe
Subject: Re: [cfe-commits] r172047 - /cfe/trunk/lib/CodeGen/CGExprScalar.cpp
On Thu, Jan 10, 2013 at 1:11 AM, David Tweed
Author: davidtweed
Date: Thu Jan 10 04:42:08 2013
New Revision: 172053
URL: http://llvm.org/viewvc/llvm-project?rev=172053view=rev
Log:
r172047 lacked a test (due to incomplete OpenCL support in clang). Use a
modified
version of a test by Joey Gouly to use attributes to materialise the
Joey Gouly pointed out how to fake missing stuff using attributes, so test
added in r172053.
From: Chandler Carruth [mailto:chandl...@google.com]
Sent: 10 January 2013 09:32
To: David Tweed
Cc: llvm cfe
Subject: Re: [cfe-commits] r172047 - /cfe/trunk/lib/CodeGen/CGExprScalar.cpp
On Thu, Jan 10
|This test breaks on a Release-Asserts build with CMake+ninja. The
|generated IR is:
Thanks for reporting. I'll change the name regexps to be more general, but I
wonder why it's happening? I'd thought the command line was suitably specific,
though I'm using configure+make. It'd be a bit
Hi, thanks for the review. I'll make the changes requested. With respect to
| Presumably, -fsanitize=shift should be disabled for OpenCL. It's
| included in -fsanitize=undefined, which should only catch undefined
| behavior.
I think the spirit is right. However, what I'll do is add an
Author: davidtweed
Date: Mon Jan 7 10:43:27 2013
New Revision: 171755
URL: http://llvm.org/viewvc/llvm-project?rev=171755view=rev
Log:
Scalar shifts in the OpenCL specification (as of v. 1.2) are defined to be
with respect to the lower left-hand-side bitwidth bits, even when negative);
see
Hi,
LLParser::ParseCmpPredicate has two uses of TokError in a switch which,
currently, fall through so an invalid cmp operand can becomes a valid,
different parse. I don't really understand the big picture of the codeI can fix
that either by doing return TokError(...) or adding a break. Using
Sorry: I'm all over the codebase these days and didn't think about it. This is
an LLVM issue not a clang one, I'll repost there.
From: cfe-commits-boun...@cs.uiuc.edu [cfe-commits-boun...@cs.uiuc.edu] On
Behalf Of David Tweed [david.tw...@arm.com]
Sent
no objections, I'll commit in a day or two.
From: cfe-commits-boun...@cs.uiuc.edu [cfe-commits-boun...@cs.uiuc.edu] On
Behalf Of David Tweed [david.tw...@arm.com]
Sent: Friday, December 21, 2012 5:51 PM
To: Jordan Rose
Cc: cfe-commits@cs.uiuc.edu
Subject: Re: [cfe
Hi,
One of the corner cases for C family languages is shifts ( and ) where the
shift size is not with 0 to word width. In C99 (and I think most other C
variants) these are undefined while OpenCL defines the meaning to be along the
lines of integer promote shift variable as required, promote
which shouldn't be being
done in the Sema layer.
Regards,
Dave
From: Jordan Rose [jordan_r...@apple.com]
Sent: Friday, December 21, 2012 5:13 PM
To: David Tweed
Cc: cfe-commits@cs.uiuc.edu
Subject: Re: [cfe-commits] [PATCH] fix shifts that are defined
. As
regards address space qualifier numbering, the current SPIR draft on
www.khronos.org/registry/cl still specifies this mapping in sec 2.2 on page
14.
Regards,
Dave
-Original Message-
From: Benyei, Guy [mailto:guy.ben...@intel.com]
Sent: 09 December 2012 07:25
To: Richard Smith; David Tweed
Cc
| Nit: Use clang -cc1 and -verify instead of clang -Werror.
Actually, could you use %clang_cc1 instead of open-coding a clang_cc1.
(Using appropriate lit macros is occasionally very helpful when you have to
debug tests.)
Regards,
Dave
___
others, there's been one positive response from Pekka,
but we're trying to ensure silence==acceptance rather than ==didn't see
mail.)
Regards,
Dave
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 30 November 2012 10:23
To: David Tweed; David Tweed; 'Eli Friedman
ping for comments/objections/exasperation on this general approach?
Regards,
Dave
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 27 November 2012 16:11
To: David Tweed; 'Eli Friedman'
Cc: 'Pekka Jääskeläinen'; 'cfe-commits@cs.uiuc.edu'
Subject: RE: [PATCH v2
Revised patch actually attached.
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 27 November 2012 16:09
To: 'Eli Friedman'
Cc: Pekka Jääskeläinen; cfe-commits@cs.uiuc.edu
Subject: RE: [PATCH v2] Set some OpenCl specification mandated
types/alignments/etc
Hi Eli
Hi Eli, thanks for the feedback. In general I've tested everything I know
how to test using only the output of a compilation.
| Why are you messing with LargeArrayMinWidth and LargeArrayAlign?
| Please explain in the patch and add tests.
That looks like something I forgot was an implementation
trying
to produce a widely portable OpenCL implementation on top of
Clang/LLVM.
http://pocl.sourceforge.net
It should make it easier to support 32-bit targets:
https://bugs.launchpad.net/pocl/+bug/911911
Thanks!
On 11/23/2012 11:11 AM, David Tweed wrote:
Just to keep this on the radar
, it's desirable to keep as much really standard OpenCL
stuff within the mainstream clang front-end rather than in implementor specific
patches.)
Cheers,
Dave
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On Behalf Of David Tweed
Sent: 22
November 2012 23:42
To: David Tweed
Cc: llvm cfe
Subject: Re: [cfe-commits] [PATCH] Set some OpenCl specification mandated
types/alignments/etc
On Wed, Nov 21, 2012 at 3:52 AM, David Tweed david.tw...@arm.com wrote:
Hi,
the attached patch sets uses setForcedLangOptions to set certain
types
Hi,
the attached patch sets uses setForcedLangOptions to set certain
types/alignments/etc which are completely specified by the OpenCL or SPIR
specs. There's also a test for those things directly exposed at the user level.
(The test is in Misc because the only specific OpenCL directory is for
Hi Rafael,
This looks like a reasonable goal, but obviously the ARM architecture being
quite modular there are a lot more actual variants (and a huge number more
potential variants) than for other CPUs (and those listed in the table). Is
there any nice mechanism for checking if an enum is one
This looks like a reasonable goal, but obviously the ARM architecture being
quite modular there are a lot more actual variants (and a huge number more
potential variants) than for other CPUs (and those listed in the table).
Is there any nice mechanism for checking if an enum is one of a list of
Hi David,
| Seems like this was the last missing bit for clang tests to pass on
| Debian armhf!
Ah, so are you getting a clean pass on the clang tests on an armhf platform?
Wei-Ren Chen is also getting a clean pass. I'm not :-( . On my ARM Pandaboard
test machine I'm seeing two intermittent
Author: davidtweed
Date: Fri Oct 26 05:17:44 2012
New Revision: 166765
URL: http://llvm.org/viewvc/llvm-project?rev=166765view=rev
Log:
These tests require an actual x86 registered target, so mark them as such.
Tested on ARM.
Patch by Joey Gouly.
Modified:
To: David Tweed; 'Dmitri Gribenko'
Cc: cfe-commits@cs.uiuc.edu
Subject: RE: [cfe-commits] r166679 - in /cfe/trunk/lib: Basic/Targets.cpp
CodeGen/TargetInfo.cpp
Hi David,
Those two tests need a x86-64 target to run, some ARM builders only target
ARM, so these fail.
The attached patch fixes
Hi all,
Just to point out something that some LLVM/clang contributors may not have
noticed. Historically the regression tests on ARM (and hence the
buildbots) have had quite a few longstanding failures, which made seeing any
new regressions difficult. Over the past couple of months various people
Author: davidtweed
Date: Thu Oct 25 08:33:01 2012
New Revision: 166679
URL: http://llvm.org/viewvc/llvm-project?rev=166679view=rev
Log:
Modify the targets to set appropriate calling convention defaults and C
variables when using a gnueabihf or aapcs-vfp target.
Tested by me and Wei-Ren Chen.
Author: davidtweed
Date: Thu Oct 25 08:56:30 2012
New Revision: 166681
URL: http://llvm.org/viewvc/llvm-project?rev=166681view=rev
Log:
Correct test inovocations to use %clang_cc1 rather than direct invocation (so
that it can have additional options set when trying to debug issues causing
Hi, Alex pointed out that the previous version of the patch didn't alter the
C macros set by the target. This updated version of the patch does that in a
conservative way updating the macros set when the aapcs-vfp PCS is used. To
my understanding, I don't believe that aapcs + hard float is
[Resend as first copy appears to have got lost before making the list]
Hi, Alex pointed out that the previous version of the patch didn't alter the
C macros set by the target. This updated version of the patch does that in a
conservative way updating the macros set when the aapcs-vfp PCS is used.
Hi, ping:
is there anyone who thinks this patch is actually the wrong thing to do?
Cheers,
Dave
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On Behalf Of David Tweed
Sent: 19 October 2012 08:52
To: 'llvm cfe'; '陳韋任 (Wei-Ren Chen
| You probably also need some changes in Basic/Targets.cpp as well to make
-gnueabihf be equivalent to EABI with -mfloat-abi=hard.
Thanks for analysing this, I'll take a look.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
Hi, I think that I've finally got a correct solution for the regression
tests failing due to the change to gnueabihf in the latest ubuntu which
implies aapcs-vfp should be the defaultCC unless additional command line
switches are set. (The code in target info somewhat ad hoc dealing with an
ad hoc
Hi Wei-Ren,
The whole configuration-ABI stuff is very, very confusing (at least to a
bear of little brain like me :-) ), which is partly why it's taken so long to
figure out this patch.
| Attach is my system parameters, and here is my current configuration,
|
|env CC=ccache /usr/bin/gcc
Hi
I've just finished a test run with this patch on an ubuntu gnueabihf pandaboard
and the constructor failures are now gone.
Thanks for working on getting the regression fixed.
Cheers,
Dave
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-boun...@cs.uiuc.edu]
On Behalf Of Logan
Hi, a relatively mechanical patch to convert some literal %clang -cc1
regression tests into %clang_cc1. It's not an earthshattering patch, but
because -cc1 is so special it means you can't test if something would fix a
regression using the equivalent command-line option by monkeying with
Oops: here's the patch.
-Original Message-
From: David Tweed
Sent: 12 October 2012 13:33
To: cfe-commits@cs.uiuc.edu
Subject: Use canonical %clang_cc1 macro in regression tests
Hi, a relatively mechanical patch to convert some literal %clang -cc1
regression tests into %clang_cc1. It's
what
the configuration differences could be to cause that.
-Original Message-
From: Stepan Dyatkovskiy [mailto:stpwo...@narod.ru]
Sent: 28 September 2012 09:59
To: David Tweed
Cc: 'Galina Kistanova'; llvm-comm...@cs.uiuc.edu; 'llvm cfe'; '陳韋任 (Wei-Ren
Chen)'; Amara Emerson
Subject: Re
Hi, I haven't quite completed my internal testing yet, but since you're
making modifications to the buildbots:
according to
http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/3118/ste
ps/configure/logs/stdio
you're configuring with armv7l-unknown-linux-gnueabi. Could you change
there's no integrated gives no feedback
about how all these checks have influenced the paths it knows about, etc.
I'm not sure if this is something worth trying to address.
Thanks,
David
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 27 September 2012 10:03
signatures which FileCheck regexps doesn't understand.)
Many thanks, and sorry for the confusion.
Cheers,
David
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 27 September 2012 11:21
To: David Tweed; 'Galina Kistanova'; 'llvm-comm...@cs.uiuc.edu'; 'llvm cfe'
Cc
Thanks for committing. I think the bug can be close.
-Original Message-
From: 陳韋任 (Wei-Ren Chen) [mailto:che...@iis.sinica.edu.tw]
Sent: 21 September 2012 08:23
To: 陳韋任 (Wei-Ren Chen)
Cc: David Blaikie; David Tweed; cfe-commits@cs.uiuc.edu
Subject: Re: [cfe-commits] Fixing clang tests
| I tried your trick, and the result is very close to yours (see attach). Ya!
Excellent.
| Aren't aapcs the ARM calling convention standard? Why it's not the default on
|ARM platform, and we need to spell it out?
My understanding, such as it is, is that some older arm platforms use something
| Quick question. Did you build with --enable-optimized?
Not on that particular build, but I do sometimes build with
--enable-optimized and it IIRC it's never affected whether a test passes or
fails (just obviously if I can inspect the core dumps, etc).
Cheers,
Dave
=cortex-a9 --with-fpu=neon --with-abi=aapcs --with-float=hard
--enable-assertions
Cheers,
Dave
-Original Message-
From: 陳韋任 (Wei-Ren Chen) [mailto:che...@iis.sinica.edu.tw]
Sent: 19 September 2012 10:01
To: David Tweed
Cc: 陳韋任 (Wei-Ren Chen); James Molloy; cfe-commits@cs.uiuc.edu
Subject: Re
/ARM ABI differences
Hi all,
This is a patch, similar to the patch by David Tweed in r163564.
It adds explicit target triples to two tests to compensate for differences
in Itanium and ARM ABIs:
CodeGenCXX/compound-literals.cpp, CodeGenCXX/throw-expression-cleanup.cpp
priority than looking at other issues encountered using LLVM on ARM.
(Apologies for the slow reply: building everything from scratch on a pandaboard
took a while...)
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 19 September 2012 11:00
To: '陳韋任 (Wei-Ren Chen)'
Cc
that it's a specific
platform-unfixable issue peculiar to arm*-linux-eabi then it would be fine to
XFAIL such tests on ARM. (Clearly if it's actually something fixable it ought
to be fixed :-) ) But I don't think we want to XFAIL tests that are passing.
Regards,
David Tweed
-Original
-Original Message-
From: 陳韋任 (Wei-Ren Chen) [mailto:che...@iis.sinica.edu.tw]
Sent: 18 September 2012 13:27
To: David Tweed
Cc: '陳韋任 (Wei-Ren Chen)'; James Molloy; cfe-commits@cs.uiuc.edu
Subject: Re: [PATCH] Mark ARCMT test cases as XFAIL on ARM
On Tue, Sep 18, 2012 at 01:12:57PM
, this is the test case's flaw as be discussed in [2].
I've had a look over these two patches and they both look good to me.
Cheers,
David Tweed
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe
to fix
those test failures on ARM?
-Original Message-
From: David Tweed [mailto:david.tw...@arm.com]
Sent: 07 September 2012 08:56
To: 'David Blaikie'
Cc: John McCall; cfe-commits@cs.uiuc.edu; 陳韋任
Subject: RE: [cfe-commits] [PATCH v2] Fixing some clang tests where ARM C++
ABI differs
Hi
1 - 100 of 105 matches
Mail list logo
