[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Dlang Bot  ---
dlang/dmd pull request #14830 "fix Issue 21492 - betterC: TypeInfo is generated
for code guarded by …" was merged into master:

- f90b298ca578c00104b0121ea2ecfacdd76f9827 by Walter Bright:
  fix Issue 21492 - betterC: TypeInfo is generated for code guarded by
if(__ctfe)

https://github.com/dlang/dmd/pull/14830

--

[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #14830 "fix Issue 21492 - betterC:
TypeInfo is generated for code guarded by …" fixing this issue:

- fix Issue 21492 - betterC: TypeInfo is generated for code guarded by
if(__ctfe)

https://github.com/dlang/dmd/pull/14830

--

[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
What D does is generate the code, then prune away all the false code blocks.
Looks like ldc does it is better.

--

[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=21482

--

[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

--- Comment #1 from dave287...@gmail.com ---
The error message has been change to “uses the GC”, but still fails. Dead
branches like this should be pruned so that more things will work with betterC.

--

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8991

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--

[Issue 18930] __ctfe fails to detect initialization of unions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18930

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P2

--

[Issue 21492] betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@ibuclaw updated dlang/dmd pull request #7509 "Fix Issue 18119 - Mark
if(__ctfe) blocks as SCOPEctfe" fixing this issue:

- Fix Issue 18119 - Mark if(__ctfe) blocks as SCOPEctfe

https://github.com/dlang/dmd/pull/7509

--

[Issue 22261] import expression does not work in __ctfe context

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22261

moonlightsenti...@disroot.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||moonlightsentinel@disroot.o
   ||rg
 Resolution|--- |INVALID

--- Comment #1 from moonlightsenti...@disroot.org ---
The supplied code never enters CTFE because semantic analysis fails with the
aforementioned error.

See https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

--- Comment #5 from Dlang Bot  ---
dlang/dmd pull request #13140 "merge stable" was merged into master:

- fab4bfe3f00ea57b4f8c6121fa73b7a9a51b by Boris Carvajal:
  Fix Issue 6 - [REG 2.095.1] __ctfe + function call in conditional
expression used to initialize struct member in constructor causes ICE (#12995)

https://github.com/dlang/dmd/pull/13140

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

--- Comment #4 from Dlang Bot  ---
dlang/dmd pull request #13129 "[stable] Cherry-pick #12995 (backend ICE)" was
merged into stable:

- ba06e7ab18a213f8f59f1f7263c13734bcad4936 by Boris Carvajal:
  Fix Issue 6 - [REG 2.095.1] __ctfe + function call in conditional
expression used to initialize struct member in constructor causes ICE (#12995)

https://github.com/dlang/dmd/pull/13129

--

[Issue 22261] New: import expression does not work in __ctfe context

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22261

  Issue ID: 22261
   Summary: import expression does not work in __ctfe context
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: tta...@gmail.com

It would be nice if we can use import expressions in __ctfe context as shown
below.

run.dlang.io: https://t.co/ui274K3Vqa?amp=1

```dlang
import std;

void main()
{
enum str = load(__FILE__);
}

auto load(string path)
{
if (__ctfe)
{
return import(path);
}
else
{
return readText(path);
}
}
```

It fails to compile with the following message:
```console
> rdmd playground.d
onlineapp.d(12): Error: variable `path` cannot be read at compile time
```

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dlang Bot  ---
dlang/dmd pull request #12995 "Fix Issue 6 - [REG 2.095.1] __ctfe +
function call in conditional…" was merged into master:

- 294a4b3e1da7ca02532cea053ecfcc52af7f077b by Boris Carvajal:
  Fix Issue 6 - [REG 2.095.1] __ctfe + function call in conditional
expression used to initialize struct member in constructor causes ICE

https://github.com/dlang/dmd/pull/12995

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@BorisCarvajal created dlang/dmd pull request #12995 "Fix Issue 6 - [REG
2.095.1] __ctfe + function call in conditional…" fixing this issue:

- Fix Issue 6 - [REG 2.095.1] __ctfe + function call in conditional
expression used to initialize struct member in constructor causes ICE

https://github.com/dlang/dmd/pull/12995

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

kinke  changed:

   What|Removed |Added

   Keywords||backend
 CC||ki...@gmx.net

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

Paul Backus  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

--- Comment #1 from Paul Backus  ---
Introduced by this PR:
https://github.com/dlang/dmd/pull/12163

--

[Issue 22226] [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

Paul Backus  changed:

   What|Removed |Added

 Blocks||22117


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=22117
[Issue 22117] Can't store scope pointer in a SumType
--

[Issue 22226] New: [REG 2.095.1] __ctfe + function call in conditional expression used to initialize struct member in constructor causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6

  Issue ID: 6
   Summary: [REG 2.095.1] __ctfe + function call in conditional
expression used to initialize struct member in
constructor causes ICE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: snarwin+bugzi...@gmail.com

As of DMD 2.097.2, attempting to compile the following program causes DMD to
crash due to a segmentation fault:

---
struct A {}

A move(A a) { return A.init; }

struct SumType
{
A a;

this(A value)
{
a = __ctfe ? value : move(value);
}
}
---

According to run.dlang.io, this is a regression introduced in DMD 2.095.1:

---
Up to  2.094.1: Success and no output
Since  2.095.1: Segfault and no output
---

Attempting to compile the above program using a build of DMD with assertions
enabled results in the following error message:

---
dmd: src/dmd/backend/cod3.d:1391: Assertion `t' failed.
---

--

[Issue 21492] New: betterC: TypeInfo is generated for code guarded by if(__ctfe)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21492

  Issue ID: 21492
   Summary: betterC: TypeInfo is generated for code guarded by
if(__ctfe)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: betterC, CTFE
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dave287...@gmail.com

Example code that demonstrates the issue, compiled with dmd and the -betterC
flag

DMD64 D Compiler v2.094.2

int bar(){
if(__ctfe){
int[] foo = [1]; // Error: TypeInfo cannot be used with -betterC
}
return 0;
}

The same code compiles with ldc without issue.

My understanding of the difference between the two compilers is that ldc
doesn’t generate code at all for `if`s that have compile-time known
constant-expressions with no labels. I don’t know how dmd works, but presumably
it is instead relying on the backend optimizing out the dead branch?

In other words, the __ctfe is not treated as a special case by ldc. The same
result is seen with this code, which compiles with ldc but fails with dmd:

int bar(){
if(false){
int[] foo = [1];
}
return 0;
}


I’m posting this as an issue as it means that betterC code that compiles with
ldc won’t compile with dmd. betterC is under-specified, so I don’t know if ldc
is being overly-permissive or if dmd is improperly detecting betterC violations
when it attempts to generate code instead of during semantic analysis.

This issue crops up if you want CTFE-able code that calculates something
inefficiently at ctfe while it just calls some external function at runtime.

--

[Issue 15590] 0 coverage should be ignored in __ctfe branches

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15590

Basile-z  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Basile-z  ---


*** This issue has been marked as a duplicate of issue 20931 ***

--

[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

[Issue 18930] __ctfe fails to detect initialization of unions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18930

Simen Kjaeraas  changed:

   What|Removed |Added

   Keywords||CTFE, diagnostic
 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
Unions generally don't work in CTFE. This issue is actually just a case of a
wrong error message - the correct error message is 'Error: reinterpretation
through overlapped field array is not allowed in CTFE', as can be seen in this
code:

union U
{
int a;
int b;
}

int fn()
{
U u;
u.a = 3;
return u.b;
}

enum v = fn();

--

[Issue 18930] New: __ctfe fails to detect initialization of unions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18930

  Issue ID: 18930
   Summary: __ctfe fails to detect initialization of unions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

---
union TwoInts
{
struct
{
int _0;
int _1;
}
int[2] array;
}
private int sum()
{
auto twoValues = TwoInts();
twoValues._0 = 100;
twoValues._1 = 200;
int x;
foreach(i; 0..2)
{
x += twoValues.array[i];
}
return x;
}

//enum v = sum(); // ERROR

void main()
{
import core.stdc.stdio;
printf("sum is %d\n", sum());
}
---

If you uncomment the `enum v = sum();` AND comment out the print line you'll
get this error:

bug.d(18): Error: `twoValues.array[cast(uint)i]` is used before initialized
bug.d(6):originally uninitialized here
bug.d(23):called from here: `sum()`

--

[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

Iain Buclaw <ibuc...@gdcproject.org> changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw <ibuc...@gdcproject.org> ---
The suggestion was to make the following condition statements as
specializations.

if (__ctfe) { }
if (!__ctfe) { }

Then, anything in the __ctfe branch that can be evaluated at compile time but
would otherwise cause a GC allocation at runtime would be permissible in @nogc
functions.

--

[Issue 18119] New: Allow code that may allocated inside __ctfe condition branches in @nogc functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18119

  Issue ID: 18119
   Summary: Allow code that may allocated inside __ctfe condition
branches in @nogc functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

Original suggestion from here: https://github.com/dlang/dmd/pull/3572

--

Re: Why isn't there more if(__ctfe) in std.math ?

[ag0aep6g via Digitalmars-d-learn]

On 09/23/2017 11:46 PM, user1234 wrote:
"if (__ctfe) {}" is a test happening at runtime. Both the if and the 
else branches got compiled, this implies:

- more code to cache
- slower code
just to allow CTFE.


__ctfe is a constant, though. Any half-decent optimizer will throw away 
the path that's not taken. dmd does it even without the optimization 
flag -O.

Re: Why isn't there more if(__ctfe) in std.math ?

[user1234 via Digitalmars-d-learn]

On Saturday, 23 September 2017 at 18:23:12 UTC, Juraj Mojzis 
wrote:

Hi,
browsing trough phobos bugzilla I found a couple of open issues 
regarding CTFE and basic math functions ( Issue 4177, 5227).
It looks to me that at least floor/ceil could by fixed by a 
simple:

if (__ctfe) return simple_floor_impl(x);

But that looks too easy and would surely be implemented 
already. So I would like to ask what the real problems are.


Thanks,
Juraj


"if (__ctfe) {}" is a test happening at runtime. Both the if and 
the else branches got compiled, this implies:

- more code to cache
- slower code
just to allow CTFE.


CTFE rounding can be more simply done using cast(int), although 
for negative numbers the behavior is not the same.

Why isn't there more if(__ctfe) in std.math ?

[Juraj Mojzis via Digitalmars-d-learn]

Hi,
browsing trough phobos bugzilla I found a couple of open issues 
regarding CTFE and basic math functions ( Issue 4177, 5227).
It looks to me that at least floor/ceil could by fixed by a 
simple:

if (__ctfe) return simple_floor_impl(x);

But that looks too easy and would surely be implemented already. 
So I would like to ask what the real problems are.


Thanks,
Juraj

[Issue 15590] 0 coverage should be ignored in __ctfe branches

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15590

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--

[Issue 15590] 0 coverage should be ignored in __ctfe branches

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15590

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Summary|the coverage fails in   |0 coverage should be
   |__ctfe branches |ignored in __ctfe branches

--- Comment #1 from b2.t...@gmx.com ---
Since coverage is generated by the target application, it cannot know if the
compiler has run it.

--

[Issue 15590] New: the coverage fails in __ctfe branches

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15590

  Issue ID: 15590
   Summary: the coverage fails in __ctfe branches
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

compile & run with -cov -unittest -main

   |auto foo()
   |{
  1|    if(__ctfe)
000|return 1;
   |else
  1|return 0;
   |}
   |
   |unittest
   |{
   |static assert(foo());
  1|assert(!foo());
   |}
/home/basile/Bureau/temp/a.d is 75% covered

The process returns 0, meaning that the __ctfe branch has returned 1 and that
consequently the static assertion is correct, however coverage does not detect
it.

The problem is that because of this a module with __ctfe branches and static
assertions can't reach 100% coverage.

--

[Issue 13601] [REG2.064] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to 2.067 at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/084a06583549525f7f7fa1c23bbd9164ce74e319
fix Issue 13601 - static if (__ctfe) should emit error

https://github.com/D-Programming-Language/dmd/commit/ff8313c25377699be5ce61bcf21d51d352b45ad5
Merge pull request #4084 from 9rnsr/fix13601

--

[Issue 13601] [REG2.064] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/084a06583549525f7f7fa1c23bbd9164ce74e319
fix Issue 13601 - static if (__ctfe) should emit error

https://github.com/D-Programming-Language/dmd/commit/ff8313c25377699be5ce61bcf21d51d352b45ad5
Merge pull request #4084 from 9rnsr/fix13601

[REG2.064] Issue 13601 - static if (__ctfe) should emit error

--

[Issue 13601] [REG2.064] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #7 from Ketmar Dark ket...@ketmar.no-ip.org ---
sorry for the noise, it seems that i was unintentionally offensive once again
in comment #2. what i really wanted to say is that my patch is in no way ready
to go to official repository, it's just a crude hack. use it on your own risk
and only if you want to have some diagnostics right away without waiting until
someone will write a proper patch.

i'm sorry.

--

[Issue 13601] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

Summary|static if (__ctfe) should   |static if (__ctfe) should
   |emit warning|emit error

--

[Issue 13601] [REG2.064] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

Summary|static if (__ctfe) should   |[REG2.064] static if
   |emit error  |(__ctfe) should emit error

--

[Issue 13601] [REG2.064] static if (__ctfe) should emit error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||accepts-invalid, pull

--- Comment #8 from Kenji Hara k.hara...@gmail.com ---
https://github.com/D-Programming-Language/dmd/pull/4084

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #5 from Martin Nowak c...@dawg.eu ---
This commit introduced the regression.
https://github.com/D-Programming-Language/dmd/commit/43a6c87194cae799650249b10a4f7c910081d280

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

   Priority|P1  |P3
 CC||c...@dawg.eu
   Severity|enhancement |regression

--- Comment #3 from Martin Nowak c...@dawg.eu ---
This worked as expected 2.063.2.

cat  bug.d  CODE
void foo()
{
static if (__ctfe) {}
}
CODE

dmd -c bug

bug.d(3): Error: variable __ctfe cannot be read at compile time


--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #4 from Martin Nowak c...@dawg.eu ---
This commit
https://github.com/D-Programming-Language/dmd/commit/021097056744c23231427b71e65bd04abc72d3e3
added a diagnostic regeression, making static if (__ctfe) print two errors.

bug.d(3): Error: variable __ctfe forward referenced
bug.d(3): Error: variable __ctfe cannot be read at compile time

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

--- Comment #6 from Martin Nowak c...@dawg.eu ---
Mmh, this happens because the static if expression is now handled by CTFE
instead of constant folding.
CTFE would need to look at the scope flags to check whether __ctfe can be read.

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Ketmar Dark ket...@ketmar.no-ip.org changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org ---
that's only if the author wants to go to mainline. me not. i don't care anymore
if my code will lang into the oficial branch or not. it's just a patch for
those who interested to patch dmd manually and either trust me or will write
test themselves.

--

[Issue 13601] New: static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

  Issue ID: 13601
   Summary: static if (__ctfe) should emit warning
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

Created attachment 1445
  -- https://issues.dlang.org/attachment.cgi?id=1445action=edit
warn on `static if (__ctfe)`

there is no much sense in doing `static if (__ctfe) …`, and this is common
mistake. even seasoned D developers aren't prone to it. so i think that
compiler should warn us about it. i wrote somewhat hacky but working code for
this.

--

[Issue 13601] static if (__ctfe) should emit warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13601

Dicebot pub...@dicebot.lv changed:

   What|Removed |Added

 CC||pub...@dicebot.lv

--- Comment #1 from Dicebot pub...@dicebot.lv ---
Any DMD changes need relevant test cases added

--

Why if(__ctfe)?

[Ilya Yaroshenko via Digitalmars-d-learn]

Why not static if(__ctfe) ?

Re: Why if(__ctfe)?

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 16 September 2014 at 13:11:50 UTC, Ilya Yaroshenko 
wrote:

Why not static if(__ctfe) ?


ctfe is a runtime condition. The function has the same code when 
run at compile time, it is just being run in a different 
environment.

Re: Why if(__ctfe)?

[Ilya Yaroshenko via Digitalmars-d-learn]

On Tuesday, 16 September 2014 at 13:28:17 UTC, Rene Zwanenburg 
wrote:
On Tuesday, 16 September 2014 at 13:17:28 UTC, Adam D. Ruppe 
wrote:
On Tuesday, 16 September 2014 at 13:11:50 UTC, Ilya Yaroshenko 
wrote:

Why not static if(__ctfe) ?


ctfe is a runtime condition. The function has the same code 
when run at compile time, it is just being run in a different 
environment.


Note that if(__ctfe) does not incur a runtime performance 
penalty. Even in debug builds will the branch be removed.


It is a kind of magic ;)

Re: static if (__ctfe)

[Timon Gehr via Digitalmars-d-learn]

On 05/07/2014 12:07 PM, Yuriy wrote:

On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote:

On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:

Hello, is there any way to static if(__ctfe)? I want to declare class
members which are only available in ctfe. Thanx.


Sadly not as far as I know. What's the use-case? There may be a nice
solution none-the-less.


Well, i'm currently playing with std.variant so it can be ctfe-friendly.
And it works pretty much, however i need to use T.stringof.ptr/length
instead of typeid (typeid is ctfeable), and i'm not sure if it's good
for performance in runtime. So for type comparison i'd like to compare
TypeInfos in rt, and T.stringof in ct. Using both with rt if will likely
generate more code.


I'd suggest to just look into making typeid's comparable in CTFE.
I have grepped around DMD's source code a little bit, but I am not 
familiar with it. (And I don't want to get involved in DMD development, 
because the code base is horrid.)


If you add in ctfeexpr.c/isCtfeComparable the conjunct 'x-op != 
TOKsymoff' (which probably is a very blunt way of enabling typeid 
comparisons and should be done more precisely), then you will notice 
that comparisons now work but always return 'false' for some types. I 
have attempted a fix for this for classes as follows in typinf.c:


TypeInfoDeclaration *TypeClass::getTypeInfoDeclaration(){
  if(!sym-vclassinfo){
if (sym-isInterfaceDeclaration())
  return TypeInfoInterfaceDeclaration::create(this); // still buggy!
else{
  sym-vclassinfo = TypeInfoClassDeclaration::create(this);
}
  }
  return sym-vclassinfo;
}

I.e. the problem is that the frontend always creates new 
TypeInfoDeclarations instead of reusing a single existing one.


After this, typeid comparisons appear to work correctly for classes at 
least.
You might look into getting this fixed completely for all types (or at 
least file a bug containing the above information.)

static if (__ctfe)

[Yuriy via Digitalmars-d-learn]

Hello, is there any way to static if(__ctfe)? I want to declare 
class members which are only available in ctfe. Thanx.

Re: static if (__ctfe)

[John Colvin via Digitalmars-d-learn]

On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:
Hello, is there any way to static if(__ctfe)? I want to declare 
class members which are only available in ctfe. Thanx.


Sadly not as far as I know. What's the use-case? There may be a 
nice solution none-the-less.

Re: static if (__ctfe)

[Yuriy via Digitalmars-d-learn]

On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote:

On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:
Hello, is there any way to static if(__ctfe)? I want to 
declare class members which are only available in ctfe. Thanx.


Sadly not as far as I know. What's the use-case? There may be a 
nice solution none-the-less.


Well, i'm currently playing with std.variant so it can be 
ctfe-friendly. And it works pretty much, however i need to use 
T.stringof.ptr/length instead of typeid (typeid is ctfeable), and 
i'm not sure if it's good for performance in runtime. So for type 
comparison i'd like to compare TypeInfos in rt, and T.stringof in 
ct. Using both with rt if will likely generate more code.

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[Gopan]

On Friday, 21 February 2014 at 17:04:45 UTC, Ali Çehreli wrote:

On 02/21/2014 08:46 AM, Gopan wrote:

 On Friday, 21 February 2014 at 14:04:45 UTC, FreeSlave wrote:
 Another strange thing:

 import std.stdio;

 uint Test()
 {
 if (!__ctfe)
 {
 return 3;
 }
 return 2;
 }



 void main()
 {
 immutable n = Test();
 int[n] arr;
 writeln(arrary length = , arr.length,  ; n = , n);
 }

 Output:
 arrary length = 2 ; n = 3

 When you think about it you understand that it's logically
right
 behavior, but it's not acceptable in practice.

 It looks like 'immutable n = Test();' is executed during both
compile
 time and runtime.  Is that what is happening?

Yes. The compiler needs the value of n at compile time so it 
evaluates it at compile time.


Thanks for confirming this, Ali.

I agree that it is confusing but I feel like it is the 
responsibility of the programmer to ensure consistent behavior.


Ali

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[Gopan]

On Friday, 21 February 2014 at 14:14:14 UTC, anonymous wrote:

Not sure if this should compile. n is a run-time value. It just
happens that it can be CTFE'd. A more problematic case:
---
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}


ie, seeing the declaration 'int[n] a;' one should not assume 
a.length is same as 'n' at runtime.  I would rather prefer 
getting a compilation error that n is not known at compile time 
and hence array declaration failed.


If this is eligible for a bugzilla, it is okay.  Otherwise, I am 
very disappointed.

immutable int n = Test(); int[n] x; ---- compiles, but __ctfe is false. How?

[Gopan]

Attempting to learn CTFE, I tried the following test.

size_t counter;

uint Test()
{
if (!__ctfe)
{
++counter;// This code is for execution at run time
}
return 2;
}

void main()
{
writeln(counter = , counter);

immutable int n = Test();
int[n] arr;
	writeln(arrary length = , arr.length,  ; counter = , 
counter);

}

output:
counter = 0
arrary length = 2 ; counter = 1

For array declaration to be successful, its size has to be known 
at compile time.  The above code compiles too.  But __ctfe seems 
to be false while performing Test().


Instead, if I write
int[Test()] c;
writeln(c.length = , c.length,  ; counter = , counter);
output is
counter = 0
c.length = 2 ; counter = 0

What is wrong in my mind?

Thanks,
Gopan

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[FreeSlave]

On Friday, 21 February 2014 at 13:38:58 UTC, Gopan wrote:

Attempting to learn CTFE, I tried the following test.

size_t counter;

uint Test()
{
if (!__ctfe)
{
++counter;// This code is for execution at run time
}
return 2;
}

void main()
{
writeln(counter = , counter);

immutable int n = Test();
int[n] arr;
	writeln(arrary length = , arr.length,  ; counter = , 
counter);

}

output:
counter = 0
arrary length = 2 ; counter = 1

For array declaration to be successful, its size has to be 
known at compile time.  The above code compiles too.  But 
__ctfe seems to be false while performing Test().


Instead, if I write
int[Test()] c;
writeln(c.length = , c.length,  ; counter = , counter);
output is
counter = 0
c.length = 2 ; counter = 0

What is wrong in my mind?

Thanks,
Gopan


Use enum n = Test() or make immutable n global variable i.e. 
place it before main.

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[FreeSlave]

Another strange thing:

import std.stdio;

uint Test()
{
if (!__ctfe)
{
return 3;
}
return 2;
}



void main()
{
immutable n = Test();
int[n] arr;
writeln(arrary length = , arr.length,  ; n = , n);
}

Output:
arrary length = 2 ; n = 3

When you think about it you understand that it's logically right 
behavior, but it's not acceptable in practice.

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[anonymous]

On Friday, 21 February 2014 at 13:38:58 UTC, Gopan wrote:

Attempting to learn CTFE, I tried the following test.

size_t counter;

uint Test()
{
if (!__ctfe)
{
++counter;// This code is for execution at run time
}
return 2;
}

void main()
{
writeln(counter = , counter);

immutable int n = Test();


As this is a local variable, this is a runtime initialization, no
__ctfe here. Doesn't matter that it's immutable. It's
static/global vs local. So, this correctly does ++counter.

Make it static immutable n, and counter won't be incremented.


int[n] arr;


Not sure if this should compile. n is a run-time value. It just
happens that it can be CTFE'd. A more problematic case:
---
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
---

	writeln(arrary length = , arr.length,  ; counter = , 
counter);

}

output:
counter = 0
arrary length = 2 ; counter = 1

For array declaration to be successful, its size has to be 
known at compile time.  The above code compiles too.  But 
__ctfe seems to be false while performing Test().


Instead, if I write
int[Test()] c;
writeln(c.length = , c.length,  ; counter = , counter);
output is
counter = 0
c.length = 2 ; counter = 0

What is wrong in my mind?

Thanks,
Gopan

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[Gopan]

On Friday, 21 February 2014 at 14:04:45 UTC, FreeSlave wrote:

Another strange thing:

import std.stdio;

uint Test()
{
if (!__ctfe)
{
return 3;
}
return 2;
}



void main()
{
immutable n = Test();
int[n] arr;
writeln(arrary length = , arr.length,  ; n = , n);
}

Output:
arrary length = 2 ; n = 3

When you think about it you understand that it's logically 
right behavior, but it's not acceptable in practice.


It looks like 'immutable n = Test();' is executed during both 
compile time and runtime.  Is that what is happening?

Re: immutable int n = Test(); int[n] x;---- compiles, but __ctfe is false. How?

[Ali Çehreli]

On 02/21/2014 08:46 AM, Gopan wrote:

 On Friday, 21 February 2014 at 14:04:45 UTC, FreeSlave wrote:
 Another strange thing:

 import std.stdio;

 uint Test()
 {
 if (!__ctfe)
 {
 return 3;
 }
 return 2;
 }



 void main()
 {
 immutable n = Test();
 int[n] arr;
 writeln(arrary length = , arr.length,  ; n = , n);
 }

 Output:
 arrary length = 2 ; n = 3

 When you think about it you understand that it's logically right
 behavior, but it's not acceptable in practice.

 It looks like 'immutable n = Test();' is executed during both compile
 time and runtime.  Is that what is happening?

Yes. The compiler needs the value of n at compile time so it evaluates 
it at compile time.


I agree that it is confusing but I feel like it is the responsibility of 
the programmer to ensure consistent behavior.


Ali

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8991



--- Comment #3 from Don clugd...@yahoo.com.au 2012-11-14 01:08:32 PST ---
I have no idea why this evil hacky code exists in Phobos, I cannot see how it
can possibly be correct. If it bypasses postblit, surely that's wrong.
If it is faster to use memcpy(), that's a compiler bug.

But anyway, it fails because it detects that two different variables are being
returned.
The workaround is easy:

+T result = void;
  if (__ctfe)
{
*cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
-T result = source;
+result = source;
return result;   //must have broke NRVO
}   

-T result = void;

Now, although it would be possible to hack IfStatement::semantic to check for
__ctfe
 or !__ctfe, and restore fd-nrvo_var, this would fail in cases like:

   if (__ctfe) {
Lnasty:
   T result = source;
   return result;
   }
   if (b)  goto Lnasty;
   T result = void;
   return result;

The problem is, that NRVO is run during the semantic pass, rather than
afterwards.
Personally I think that inlining should happen after the semantic3 pass (it
would make CTFE *much* simpler), and I think NRVO could happen then as well.
Otherwise I'm not sure that this is worth doing anything about. It is still
true that if (__ctfe ) never affects backend code generation, it's just odd
that DMD is doing NRVO in the front-end.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8991



--- Comment #4 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-14 
06:42:57 PST ---
(In reply to comment #3)
I have no idea why this evil hacky code exists in Phobos, I cannot see how it
can possibly be correct. If it bypasses postblit, surely that's wrong.
If it is faster to use memcpy(), that's a compiler bug.

The whole point of move is to avoid extra postblit and turn l-value into an
r-value.
The way to do it seems to be (and very simillar in swap) is to blit T.init into
source and whatever it contained before return as result. 
The source will eventually get destroyed with T.init. 

Thus the postblit is not required and no double destroy of the same object
happens.

While I thought this could work to paint things as r-value:
T move(ref T x ){ return x; }

it will still do a postblit as ref-ed param stays intact elsewhere.

 The workaround is easy:
 
 +T result = void;
   if (__ctfe)
 {
 *cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
 -T result = source;
 +result = source;
 return result;   //must have broke NRVO
 }   
 

That was what I did in the first place. Problem is  - it doesn't work for
structs with immutable fields as after:
T result = void; 
this line:
result = source;
does't compile. 
I wouldn't have noticed this if Phobos unittests haven't failed
while memcpy hacked through any such inconveniences.

In any case I've found a workaround that seems to pass through:
https://github.com/D-Programming-Language/phobos/pull/936

 The problem is, that NRVO is run during the semantic pass, rather than
 afterwards.
 Personally I think that inlining should happen after the semantic3 pass (it
 would make CTFE *much* simpler), and I think NRVO could happen then as well.
 Otherwise I'm not sure that this is worth doing anything about.

Okay let's either close it or turn into an enhancement request for doing
inlining and NRVO after completion of the semantic pass.

 It is still
 true that if (__ctfe ) never affects backend code generation, it's just odd
 that DMD is doing NRVO in the front-end.

Okay that makes it clearer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8991



--- Comment #2 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-11 
01:20:32 PST ---
(In reply to comment #1)
 It seems that dmd is confused by return statement within if(__ctfe) block:
 comment it out and you will get desired behavior (tested on 2.060nix).

Yeah, problem is: 
I want __ctfe branch to just do a copy and normal branch to move via memcpy and
other black magic.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8991] New: adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8991

   Summary: adding a __ctfe branch with return to a function
breaks NRVO
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com


--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-10 
03:14:36 PST ---
Sample obtained while trying to make move work (at least making a copy) during
CTFE.
In the following snippet if __ctfe section is commented out, then return value
doesn't get copied. If it's present however there is a postblit call.

The expected result is that __ctfe should never affect code generation of
run-time code.

Tested on DMD 2.061 from git master.

import core.stdc.string;

T move(T)(ref T source)
{
if (__ctfe)
{
*cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
T result = source;
return result;   //must have broke NRVO
}   

T result = void;


static if (is(T == struct))
{
static T empty;
memcpy(result, source, T.sizeof);
memcpy(source, empty, T.sizeof);
}
else
{
result = source;
}
return result;
}

unittest
{
// Issue 5661 test(2)
static struct S4
{
static struct X
{ 
int n = 0; 
this(this){n = 0;} 
}
X x;
}
S4 s41;
s41.x.n = 1;
S4 s42 = move(s41);
assert(s41.x.n == 0); //ok, memcpy-ed T.init over source
assert(s42.x.n == 1); //fails, postblit got called somewhere 
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8991


Maxim Fomin ma...@maxim-fomin.ru changed:

   What|Removed |Added

 CC||ma...@maxim-fomin.ru


--- Comment #1 from Maxim Fomin ma...@maxim-fomin.ru 2012-11-10 11:42:18 PST 
---
It seems that dmd is confused by return statement within if(__ctfe) block:
comment it out and you will get desired behavior (tested on 2.060nix).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8801] assigning to __ctfe crashes the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8801



--- Comment #1 from github-bugzi...@puremagic.com 2012-10-20 18:20:44 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f6d0cf50a5507de3b4dbd1803f757536d80c3f44
Fix issue 8801 assigning to __ctfe crashes the compiler

We need checks in two places, because constructing a variable doesn't call
toLvalue().

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8801] New: assigning to __ctfe crashes the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8801

   Summary: assigning to __ctfe crashes the compiler
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com


--- Comment #0 from monarchdo...@gmail.com 2012-10-11 06:44:49 PDT ---
2.060

//
void main()
{
bool __ctfe = true;
}
//
Internal error: ..\ztc\cgcs.c 522
//

__ctfe is a reserved word, so the code is (arguably) invalid.

Still, compiler internal error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: __ctfe

[Jonathan M Davis]

On Tuesday, October 02, 2012 09:45:10 Don Clugston wrote:
 On 01/10/12 21:30, Adam D. Ruppe wrote:
  On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote:
  Something I wanted to ask for a long time: is there any runtime speed
  penalty in using __ctfe?
  
  No. What happens is when it goes to the compile the runtime code, __ctfe
  is a constant false, so then the optimizer can see it is obviously dead
  code and eliminate the branch entirely. You don't even have to use the
 
  -O switch to get this:
 Yes, I was VERY careful about this. The if (__ctfe) branch gets
 discarded at the end of the front-end. The backend never sees it.

By the way, why is it not used in static if? That's what most of us would have 
expected (and it frequently seems to trip people up). I assume that it's due 
to some implementation detail of CTFE (like it doesn't really compile any 
functions differently for CTFE)?

- Jonathan M Davis

Re: __ctfe

[Daniel Murphy]

Jonathan M Davis jmdavisp...@gmx.com wrote in message 
news:mailman.477.1349164468.5162.digitalmar...@puremagic.com...

 By the way, why is it not used in static if? That's what most of us would 
 have
 expected (and it frequently seems to trip people up). I assume that it's 
 due
 to some implementation detail of CTFE (like it doesn't really compile any
 functions differently for CTFE)?

 - Jonathan M Davis

Code inside static if blocks does not have to be semantically valid if it is 
not selected, and is discarded well before the interpreter could be invoked 
on it.  It could be done using static if or version, but that would require 
duplicating the function and re-running semantic, which is less elegant and 
not really what you want.
There is a little bit of explanation in the original bug report: 
http://d.puremagic.com/issues/show_bug.cgi?id=3556 

__ctfe

[Philippe Sigaud]

On Mon, Oct 1, 2012 at 8:36 PM, Jonathan M Davis 
jmdavisp...@gmx.com wrote:


[Creating a new thread for this]

__ctfe exists purely so that you can provide an alternate 
implementation which
works at compile time when the normal implementation doesn't 
(since CTFE _is_
more restrictive in what it allows than running a function at 
runtime is).


Something I wanted to ask for a long time: is there any runtime 
speed penalty in using __ctfe? I have functions that are OK at 
runtime and do not work at compile-time. If I find a way to make 
them work at CT and use __ctfe to distinguish the two branches, 
will runtime execution become slower?

Re: __ctfe

[Adam D. Ruppe]

On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote:
Something I wanted to ask for a long time: is there any runtime 
speed penalty in using __ctfe?


No. What happens is when it goes to the compile the runtime code, 
__ctfe is a constant false, so then the optimizer can see it is 
obviously dead code and eliminate the branch entirely. You don't 
even have to use the -O switch to get this:


void test() {
if(__ctfe) {
asm { nop; nop; nop; nop; }
} else {
asm { hlt; }
}
}

$ dmd test.d -c
$ objdump --disassemble test.o
Disassembly of section .text._D4test4testFZv:

 _D4test4testFZv:
   0:   55  push   %ebp
   1:   8b ec   mov%esp,%ebp
   3:   f4  hlt
   4:   5d  pop%ebp
   5:   c3  ret


Note that there's no trace of a compare, jmp, nor the nops from 
the dead ctfe branch.

Re: __ctfe

[Philippe Sigaud]

On Mon, Oct 1, 2012 at 9:30 PM, Adam D. Ruppe destructiona...@gmail.com wrote:
 On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote:

 Something I wanted to ask for a long time: is there any runtime speed
 penalty in using __ctfe?


 No. What happens is when it goes to the compile the runtime code, __ctfe is
 a constant false, so then the optimizer can see it is obviously dead code
 and eliminate the branch entirely.

Cool.I feared it was a runtime-determined value, somehow.


 $ dmd test.d -c
 $ objdump --disassemble test.o
 Disassembly of section .text._D4test4testFZv:

  _D4test4testFZv:
0:   55  push   %ebp
1:   8b ec   mov%esp,%ebp
3:   f4  hlt
4:   5d  pop%ebp
5:   c3  ret


 Note that there's no trace of a compare, jmp, nor the nops from the dead
 ctfe branch.

OK, I'm sold.

Thanks!

[Issue 4177] __ctfe can't be used in pure functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4177


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-08-28 
14:55:16 PDT ---
http://www.dsource.org/projects/dmd/changeset/646

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4177] __ctfe can't be used in pure functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4177


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||patch
 CC||clugd...@yahoo.com.au
Version|future  |2.041


--- Comment #1 from Don clugd...@yahoo.com.au 2010-06-08 11:38:37 PDT ---
Since __ctfe is so magical and unique, it seems justified to give it one more
special case. Other approaches I tried (changing the storage_class of __ctfe) 
were far more complicated.

PATCH expression.c, VarExp::semantic(), line 4397.

+/* Magic variable __ctfe never violates pure or safe
+ */
+if (v-ident == Id::ctfe)
+return this;

/* If ANY of its enclosing functions are pure,
 * it cannot do anything impure.
 * If it is pure, it cannot access any mutable variables other
 * than those inside itself
 */

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4177] New: __ctfe can't be used in pure functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4177

   Summary: __ctfe can't be used in pure functions
   Product: D
   Version: future
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-05-12 04:09:05 PDT ---
To define a std.math.log() function that works at compile time (see bug 3749 )
it can be used __ctfe, but there are problems:


pure real log(real x) {
if (__ctfe)
return 0.0;
else
return 1.0;
}
enum x = log(4.0);
void main() {}


dmd v2.045 prints:

test.d(2): Error: variable __ctfe forward referenced
test.d(2): Error: pure nested function 'log' cannot access mutable data
'__ctfe'
test.d(7): Error: cannot evaluate log(4L) at compile time
test.d(7): Error: cannot evaluate log(4L) at compile time


I'd like __ctfe to work in pure functions too.
I think it can be done because it's an immutable value that I think can't break
the purity of the function/method, even if as in that example the function can
give different outouts at compile and run time.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---