August 09, 2010
On 9-ago-10, at 22:08, Walter Bright wrote:

>
>
> Fawzi Mohamed wrote:
>> On 9-ago-10, at 16:29, Fawzi Mohamed wrote:
>>
>>> [...]
>>> Yes osx needs position independent code, I have tried to replace
>>> D_PIC with IS_PIC and add
>>
>> from experimenting with gdc and the atomic module I remember that I
>> had to completly free up ebx, as it holds the Position-independent
>> code base register.
>> Even pushing & popping it would not satisfy the gdc compiler (not
>> sure why, maybe becuase signal handlers might need it?)
>>
>> In any case the abi is here
>>
>> http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#/ /apple_ref/doc/uid/TP40002492-SW4
>>
>
> The EBX must be preserved across function calls. That's the only restriction on its use. Whether within a function it is used as a base register or not is relevant only to that function, and is not part of the ABI.
>
> dmd regenerates the base register contents as required.

ok good, I just know that gdc (actually the underlying asm backend)
did not allow any change to the EBX, which I found surprising, becuase
if one doesn't perform any call or access globals I though safe to
clobber the global offset table...
As gcc/gdc did not allow it I wondered if there were hidden pitfalls
into it...


August 09, 2010

Fawzi Mohamed wrote:
>
> ok good, I just know that gdc (actually the underlying asm backend)
> did not allow any change to the EBX, which I found surprising, becuase
> if one doesn't perform any call or access globals I though safe to
> clobber the global offset table...
> As gcc/gdc did not allow it I wondered if there were hidden pitfalls
> into it...
>

I believe the older gcc did require EBX to be dedicated to being the base register, but sometime in the last 10 years it was fixed.
August 09, 2010

Walter Bright wrote:
>
>
> Don Clugston wrote:
>> Try going into bigintx86, and replacing "D_PIC" with "all". If the failing tests pass, that's the problem. And unless OSX has a concept of PIC, I think OSX should define D_PIC at all times.
>>
>> 
>
> PIC should be always on for OSX, and it's a bug if the version thing is not set for it.
>

I checked, D_PIC is always set under OSX. In mars.c:

#if TARGET_OSX
    global.params.pic = 1;
#endif

[...]

    if (global.params.pic)
        VersionCondition::addPredefinedGlobalIdent("D_PIC");
August 09, 2010
On 9-ago-10, at 22:34, Walter Bright wrote:

> Fawzi Mohamed wrote:
>>
>> ok good, I just know that gdc (actually the underlying asm backend)
>> did not allow any change to the EBX, which I found surprising,
>> becuase if one doesn't perform any call or access globals I though
>> safe to clobber the global offset table...
>> As gcc/gdc did not allow it I wondered if there were hidden
>> pitfalls into it...
>>
>
> I believe the older gcc did require EBX to be dedicated to being the base register, but sometime in the last 10 years it was fixed.

ok, then I am basing my knowledge on very old behaviour... I was afraid that signals might need the GOT from that register at any time...

By the way excluding the bug with the cast of the enum the compiler seems to work well...

August 09, 2010
It's the negass. Working on a fix.

Don Clugston wrote:
> Confirmed, that code gives a segfault on D1 Windows too. Works OK with D2.
>
> On 9 August 2010 12:46, Fawzi Mohamed <fawzi at gmx.ch> wrote:
> 
>> Thanks for the release, sorry to bring a bad news, but I still have a bus error (as with the previous beta) when compiling blip.parallel.smp.SmpModels with -O.
>>
>> I have reduced it to
>> {{{
>> module bug;
>>
>> enum TaskStatus:int{
>>    Building=-1,
>> }
>>
>> /// conversion str -> TaskStatus
>> TaskStatus taskStatusFromStr(char[] s){
>>    char[] t="TaskStatus";
>>    if (s.length>t.length && s[0..t.length]==t){
>>        long res=0;
>>        if (s[t.length]=='-') res= -res;
>>        return cast(TaskStatus)cast(int)res;
>>    }
>>    assert(0);
>> }
>> }}}
>>
>> with -O, and keeing something (so that res is not known at compile time) the cast seems to trigger an error in the compiler.
>>
>> Fawzi
>> On 9-ago-10, at 08:19, Walter Bright wrote:
>>
>> 
>>> http://ftp.digitalmars.com/dmd1beta.zip
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>> 
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
> 
August 09, 2010
New version posted to fix Fawzi's seg fault.

Walter Bright wrote:
>
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
August 09, 2010
changeset 609

Walter Bright wrote:
> It's the negass. Working on a fix.
>
> Don Clugston wrote:
>> Confirmed, that code gives a segfault on D1 Windows too. Works OK with D2.
>>
>> On 9 August 2010 12:46, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>> 
>>> Thanks for the release, sorry to bring a bad news, but I still have
>>> a bus
>>> error (as with the previous beta) when compiling
>>> blip.parallel.smp.SmpModels
>>> with -O.
>>>
>>> I have reduced it to
>>> {{{
>>> module bug;
>>>
>>> enum TaskStatus:int{
>>>    Building=-1,
>>> }
>>>
>>> /// conversion str -> TaskStatus
>>> TaskStatus taskStatusFromStr(char[] s){
>>>    char[] t="TaskStatus";
>>>    if (s.length>t.length && s[0..t.length]==t){
>>>        long res=0;
>>>        if (s[t.length]=='-') res= -res;
>>>        return cast(TaskStatus)cast(int)res;
>>>    }
>>>    assert(0);
>>> }
>>> }}}
>>>
>>> with -O, and keeing something (so that res is not known at compile
>>> time) the
>>> cast seems to trigger an error in the compiler.
>>>
>>> Fawzi
>>> On 9-ago-10, at 08:19, Walter Bright wrote:
>>>
>>> 
>>>> http://ftp.digitalmars.com/dmd1beta.zip
>>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>> _______________________________________________
>>>> dmd-beta mailing list
>>>> dmd-beta at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>> 
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>>> 
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>>
>> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
August 09, 2010
I think that shouldn't be changed back; it is one of the first applications of a useful idiom.

The compiler bugs and limitations making that example uncompilable should be addressed.

Walter, could you please take a look and assess the situation? We discussed the matter briefly on the phone and you agreed that the code is correct.


Andrei

David Simcha wrote:
> Wait a minute, I see what's going on.  Why did someone decide to nest the Filter struct inside the filter() function?  Should this just be changed back?
> 
> On 8/9/2010 9:20 AM, David Simcha wrote:
>> I'm receiving a rather inscrutable compile time error on the following test program:
>>
>> import std.stdio, std.algorithm, std.string;
>>
>> void main() {
>>     auto file = filter!"a.length > 0"(
>>         File("foo.txt").byLine()
>>     );
>> }
>>
>>
>> Error: function std.algorithm.filter!("a.length > 0").filter!(ByLine!(char,char)).filter cannot access frame of function this
>>
>> I have no idea what this error message means, but I know I've never seen it before.  AFAIK the only change to Filter since the last release has been adding a save() method.
>>
>>
>> On 8/9/2010 2:19 AM, Walter Bright wrote:
>>>
>>> http://ftp.digitalmars.com/dmd1beta.zip
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>>
> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
August 09, 2010
On Aug 9, 2010, at 6:20 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> it is one of the first applications of a useful idiom.

Just curious, what's this new, useful idiom?
August 09, 2010
Objects that can only be obtained by calling a function.

Anderi

Jason House wrote:
> On Aug 9, 2010, at 6:20 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> 
>> it is one of the first applications of a useful idiom.
> 
> Just curious, what's this new, useful idiom?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta