I agree that the warnings are usually valuable. I don't remember what we did to the I/O code or if we could turn off the errors...
I think adding the casts is a reasonable solution, but it requires that the compiler be able to reason about both types (e.g. c_ptr(c_char) and c_ptr(int(8))) at the same time... and that we can connect a variable's type to the declared type rather than the normalized type. Thanks, -michael On 3/31/15, 1:52 PM, "Brad Chamberlain" <[email protected]> wrote: > >IIRC, the last time we looked into this (on darwin for some standard >int-based typedefs), we couldn't find a way to squash these warnings. >Michael, does that sound right? (it was in some I/O tests that were >giving us some hassles on Macs... I'm also trying to remember how we >actually resolved these...) > >Even if such a flag existed, what I like about using the casts is that it >permits us to squash the cases we're treating the same based on language >features while still getting warnings in other cases that could be useful >-- i.e., it feels more precise than having a big enable/disable warning >hammer. > >-Brad > > >On Tue, 31 Mar 2015, Tom Hildebrandt wrote: > >> Assuming that the Chapel compiler has done the job of type checking, >> then type checking in the backend compiler becomes redundant. So the >> approach of turning off the warnings seems reasonable. It also appears >> easier than making sure (through explicit casts) that arguments of the >> right type are passed. >> >> The downside of squashing the warnings is that it would make codegen >> errors harder to detect. For debugging, one can always turn the >>warning >> back on in the generated makefile, so I guess that's OK. >> >> THH >> ________________________________________ >> From: Brad Chamberlain [[email protected]] >> Sent: Tuesday, March 31, 2015 9:45 AM >> To: Michael Ferguson >> Cc: [email protected] >> Subject: Re: [Chapel-developers] tracking extern types? >> >>> It's really just that C compilers emit warnings when you >>> do things with different but equivalent pointer types. >>> >>> For example, if I pass int8_t* into a routine expecting char*, >>> I usually will get a warning. And we don't like our generated >>> code giving us warnings... I suppose we could ask the C compilers >>> for fewer warnings. >> >> Alternatively, the Chapel compiler could emit a cast when passing an >> actual to a formal that is an equivalent type alias. >> >> -Brad >> >> >> >>------------------------------------------------------------------------- >>----- >> Dive into the World of Parallel Programming The Go Parallel Website, >>sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub >>for all >> things parallel software development, from weekly thought leadership >>blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Chapel-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-developers >> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
