What would you like to see in Sun Studio?

The Sun Studio team are inviting anyone to give them feedback about what features should be in the next version. Obviously, it is not going to be possible to implement every suggestion, but if you have any requests then follow the following procedure before the cut-off date of 31st October (yup, that's not too far in the future). Alternatively, paste them as comments into my blog, and I'll make sure that they get put on the list.

The procedure for filing a request for enhancement (rfe) against Sun Studio is as follows:

  • Go to http://bugreport.sun.com/bugreport/ and check the box at the bottom of the page which says that you understand that the tool is not a support mechanism, then click on "Start a new Report"
  • Select the following:
    • Type = Request for Enhancement
    • Product/Category = "C/C++/Fortran Compilers and Tools - Misc"
    • Subcategory = "C/C++/Fortran Compilers and Tools - Misc"
    • Release = "Other"
    • Operating System = choose appropriate OS
  • Click on "Continue"

On the next screen, you only need to fill out the required fields indicated by asterisks. Some notes for two of the fields:

  • The "Synopsis" field should be start with the identifier "VOC" (short for "Voice of Customer"). e.g.: "VOC: Please add this feature".
  • Complete the "Justification" field with details on why the feature is important - the more credible the reason the better.
  • Finally, click on "Submit"

Thanks for your help.

BTW, the same form can be used to report bugs in the product too - but as the check box indicates it is not a way of getting support.

Comments:

Hello,

does fixing all the bugs and improving the performance count as a feature? ;-)

I think finishing the existing incomplete compiler features (gcc-style inline asm, multimedia intrinsics) would already be nice.

Other than that, a tool (probably simply some additional compiler warnings) that helps start from a huge code base and turn it into something reasonably thread-safe (not multi-threaded, that is an other story, and you already have some tools there) would be nice (simply detecting non-const global variables at compile time would already help).

Basically I am more in favor of improving the existing tools (including dmake and the netbeans plugin) than developing something new. Now that I think about the netbeans plugin, I think it is a bad idea to remove netbeans features in studio. The fact that some things can be done in netbeans with the plugin but not in studio does not sound great (although I understand the principle).

Good luck with the next version, I really like what you already have.

Posted by Marc on October 27, 2007 at 06:51 AM PDT #

Thanks for the comments. In terms of the tool can you provide me with a few more details of the problem that you're facing? Is this library code?

Posted by Darryl Gove on October 29, 2007 at 12:45 AM PDT #

Hello,

we have a very large (roughly a million lines) base of c++ library code, developed without particular care for thread safety. Now users tell us they want to use it in threaded code and complain about the library not being thread-safe. Most of the code is pure functions and has no issues. Now we have very little resources, and auditing the whole code for non thread-safe constructs is not doable, and we don't have many ideas on how to approach the issue. So a tool that gives a list of some places where we should focus our attention would help.

While I am talking about helping our development, here is one thing that is not fundamental but could be nice. Most of our code is template code in headers that will be included by client code, and the rest is compiled into a library. It would be nice to have an easy way to make sure we don't introduce any code that generates symbols (only templates, static variables, inline functions, etc) in the headers (maybe using the fact that these files are in a different directory).

Once again, I am only saying what I have at the top of my head, if some things sound interesting to you, please use them, and if not, you can ignore them without any problem.

Posted by Marc on October 30, 2007 at 05:00 AM PDT #

Thank you, this is really useful feedback. I'll discuss it and get any necessary rfe's filed.

Posted by Darryl Gove on October 30, 2007 at 08:07 AM PDT #

Hi,

I've filed the rfe for tracking accesses to global data. That's not a commitment to do it - just ensures that it doesn't get lost in the system.

I've also passed all your comments on to the group doing VOC gathering.

I'd like to confirm that I understand what you are after when you request warnings for symbols. As I interpret the request it is you want a report on whether an included header file caused the definition of any symbols. I'm imagining the motivation for this might be to avoid the possibility of having duplicate symbols defined in the code? Is that correct? Or do you have something else in mind?

Thanks,

Darryl.

Posted by Darryl Gove on November 01, 2007 at 07:41 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Darryl Gove is a senior engineer in the Solaris Studio team, working on optimising applications and benchmarks for current and future processors. He is also the author of the books:
Multicore Application Programming
Solaris Application Programming
The Developer's Edge

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
5
6
8
9
10
12
13
14
15
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
The Developer's Edge
Solaris Application Programming
Publications
Webcasts
Presentations
OpenSPARC Book
Multicore Application Programming
Docs