Oops, never mind!  Ben A pointed out that there’s already a PR for this which 
does space-separation.  I retract my vote.   :-)

greg


> On Mar 6, 2017, at 11:14 AM, Greg Titus <[email protected]> wrote:
> 
> Just in passing, I want to put in a vote for making multiple instances of the 
> ccflags option stack, and implementing this in a way that doesn’t depend on a 
> separator character of our own.  (For example, we could do multiple 
> ‘CFLAGS+=‘ entries in the generated Makefile.)  All separators are 
> problematic — space chars because we can’t know how many shells are involved 
> and therefore cannot protect the separator adequately, and all other 
> “reasonable” characters because they can occur in the options themselves.  
> (For this latter I’m thinking especially of commas, which are the separator 
> for -Wl compiler driver options.)
> 
> And while we’re at it, we should also do ldflags.
> 
> greg
> 
> 
>> On Mar 4, 2017, at 10:02 AM, Brad Chamberlain <[email protected]> wrote:
>> 
>> 
>> Hi Przemek --
>> 
>> Thanks for pointing out this bug.  If you'd be willing to file a GitHub 
>> issue against it on our repo, that would be great.
>> 
>> The workaround I was going to suggest was the one it appears you've already 
>> tried: using multiple ccflags options to "stack" the flags You _might_ also 
>> try using the CHPL_CC_FLAGS environment variable to see if that works any 
>> better (I don't have an llvm-enabled version of the compiler handy and am 
>> trying not to work this weekend, so haven't tried it myself.  But I wouldn't 
>> be surprised if it had the same problem.
>> 
>> The variable used within the compiler to store this option is 'ccflags' 
>> which has a very small number of references in the compiler -- most related 
>> to setting it up while parsing arguments. I believe the uses in 
>> compiler/util/clangUtil.cpp are where the llvm back-end uses it and the code 
>> in compiler/util/files.cpp is where the C back-end does. Unfortunately, a 
>> quick look suggests that there isn't some pre-existing "C back-end parses 
>> the string" code to re-use because in that case we're dumping the string 
>> into a generated Makefile, and I think it's the 'make' logic that teases 
>> things apart.  So it's likely that new code would have to be written in 
>> clangUtil.cpp -- (or maybe in the representation of ccflags itself?) -- in 
>> order to fix this issue.
>> 
>> That's based on a really quick look at the code, though, so I may well be 
>> missing something else.
>> 
>> -Brad
>> 
>> 
>> On Sat, 4 Mar 2017, Przemek Leśniak wrote:
>> 
>>> There is a problem associated with passing options to backend C compiler
>>> when it is clang (in case of gcc this works fine). Clang receives options
>>> as one string being concatenation of all options and doesn't parse this.
>>> 
>>> chpl --ccflags "-mllvm -use-cfl-aa" --llvm test.chpl
>>> and
>>> chpl --ccflags -mllvm --ccflags -use-cfl-aa --llvm test.chpl
>>> 
>>> Give:
>>> 
>>> error: unknown argument: '-mllvm -use-cfl-aa'
>>> 
>>> Note that I have to use --llvm flag so that the backend compiler becomes
>>> clang (it's gcc without this flag).
>>> 
>>> chpl --ccflags "-mllvm -use-cfl-aa" test.chpl
>>> 
>>> Gives:
>>> 
>>> gcc: error: unrecognized command line option ‘-mllvm’
>>> 
>>> Which is fine.
>>> 
>>> I checked both gcc and clang compiler errors just to make sure:
>>> 
>>> gcc "-mllv -use-cfl-aa"
>>> gcc: error: unrecognized command line option ‘-mllv -use-cfl-aa’
>>> 
>>> clang "-mllv -use-cfl-aa"
>>> clang: error: unknown argument: '-mllv -use-cfl-aa'
>>> 
>>> Is there any workaround?
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! 
>> http://sdm.link/slashdot_______________________________________________
>> Chapel-bugs mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/chapel-bugs
> 

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Chapel-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-bugs

Reply via email to