On 1/17/2013 1:20 AM, Mehrdad wrote:
> Have you seen the Visual C++ 2012 compiler? It fixes that problem.
>
> Its auto-vectorizer has two switches:
>
> 1. /Qvec-report:1, which reports the auto-vectorized loops
> 2. /Qvec-report:2, which reports all potential candidates and whether or not
> they were vectorized (and if not, a reason code)

I would call it more of a workaround than a fix.

17-Jan-2013 22:48, H. S. Teoh пишет:
> On Wed, Jan 16, 2013 at 02:48:30PM +0400, Dmitry Olshansky wrote:
>> 11-Jan-2013 23:31, Dmitry Olshansky пишет:
>>>
>>> The code, including extra tests and a benchmark is here:
>>> https://github.com/blackwhale/gsoc-bench-2012
>>>
>>> And documentation:
>>> http://blackwhale.github.com/phobos/uni.html
[snip]

>>
>> - Why are the isX() functions @system? I would have expected they should
>>    be at least @trusted? (Or are there technical problems / compiler bugs
>>    preventing this?)
>>
>
> M-hm I'm seeing this in my sources:
> bool isAlpha(dchar c) @safe pure nothrow
> {...}
>
> The DDoc however shows @system.
>
> A compiler bug?

It's indeed a bug in the compiler, looks funny:
http://d.puremagic.com/issues/show_bug.cgi?id=9371

Makes me think that the compiler treats @safe after
the function prototype differently then the one placed before it.
The trailing-@safe camp must be jealous.

>> That's all for now. I hope you don't mind me allowing the grammar nazi
>> to take over for a bit. I want Phobos documentation to be professional
>> quality. :)
>>

All of these were incorporated, thanks.
Among other new stuff I've added some cross-links throughout.

Now on to the normalization forms description, etc.

-- 
Dmitry Olshansky

On Wednesday, January 23, 2013 00:20:19 Dmitry Olshansky wrote:
> It's indeed a bug in the compiler, looks funny: http://d.puremagic.com/issues/show_bug.cgi?id=9371
> 
> Makes me think that the compiler treats @safe after
> the function prototype differently then the one placed before it.
> The trailing-@safe camp must be jealous.

Prepending @safe is evil. ;)

That's definitely a weird bug though. I'd say that it pretty much has to be a bug in the parser given that the AST should be identical regardless of which side of the function signature an attribute is on.

- Jonathan m Davis