[Issue 18520] Different functions and function/delegate literals can be aliased to the same name

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

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

monkeywork...@hotmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---
Summary|Different delegates can be  |Different functions and
   |aliased to the same name|function/delegate literals
   |multiple times  |can be aliased to the same
   ||name

--- Comment #3 from monkeywork...@hotmail.com ---
Re-opening this until I can get clarification on whether it is supposed to be
an error or not to define the same alias 3 times. In my second example it
compiles and works correctly, making me think that this is a feature, not a
bug.

--

[Issue 18520] The same alias can be declared multiple times if a function or function/delegate literal is aliased

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

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

monkeywork...@hotmail.com changed:

   What|Removed |Added

Summary|Different functions and |The same alias can be
   |function/delegate literals  |declared multiple times if
   |can be aliased to the same  |a function or
   |name|function/delegate literal
   ||is aliased

--

[Issue 18520] Different delegates can be aliased to the same name multiple times

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

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

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Basile B.  ---
This due to implicit conversion which has for effect to make the first overload
always working.

a way to overcome this:

alias f(T = int) = (T n) => 0;
alias f(T = char) = (T n) => 'a';
alias f(T = bool) = (T n) => false;

--

[Issue 18520] Different delegates can be aliased to the same name multiple times

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

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

--- Comment #1 from monkeywork...@hotmail.com ---
The code seemingly functions correctly when I change it as follows:

int  f1(int n)  { return 0; }
char f2(char c) { return 'a'; }
bool f3(bool b) { return false; }

alias f = f1;
alias f = f2;
alias f = f3;

void main()
{   
import std.stdio;
writeln(f(int.init));  //Prints 0
writeln(f(char.init)); //Prints 'a'
writeln(f(bool.init)); //Prints false
}

--

[Issue 18520] New: Different delegates can be aliased to the same name multiple times

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

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

  Issue ID: 18520
   Summary: Different delegates can be aliased to the same name
multiple times
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: monkeywork...@hotmail.com

The following code compiles with DMD 2.070.2 and prints 0 three times:

alias f = (int n) => 0;
alias f = (char c) => 'a';
alias f = (bool b) => false;

void main()
{
import std.stdio;
writeln(f(int.init));  //Prints 0
writeln(f(char.init)); //Prints 0
writeln(f(bool.init)); //Prints 0
}

It looks like the int overload is getting called each time.

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

--- Comment #7 from Jonathan M Davis  ---
Well, I'm able to build and run the tests for Phobos, druntime, and dmd without
having gcc installed on a 64-bit FreeBSD 11.1 system. I'd guess that that works
for 32-bit as well (aside from the test failures that are being worked
through), but I don't know. 2.068.2 certainly won't work that way though.

--

[Issue 18480] [Reg 2.079] dmd hangs with self-alias declaration

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|dmd 2.079 hangs |[Reg 2.079] dmd hangs with
   ||self-alias declaration

--

[Issue 18519] New: freebsd 11 + phobos + curl, timing out

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

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

  Issue ID: 18519
   Summary: freebsd 11 + phobos + curl, timing out
   Product: D
   Version: D2
  Hardware: x86
OS: FreeBSD
Status: NEW
  Severity: critical
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bra...@puremagic.com

Freebsd 11, 32 bit, doesn't come with 32 bit curl libraries, but does 64 bit.

The phobos tests seem to not fast-fail, timing out:

timelimit: sending warning signal 15
gmake[1]: *** [posix.mak:377: unittest/std/net/curl.run] Error 143
gmake[1]: Leaving directory
'/media/ephemeral0/sandbox/at-client/pull-3048038-FreeBSD_32/phobos'
gmake: *** [posix.mak:297: unittest-debug] Error 2
gmake: *** Waiting for unfinished jobs
timelimit: sending warning signal 15
gmake[1]: *** [posix.mak:377: unittest/std/net/curl.run] Error 143
gmake[1]: Leaving directory
'/media/ephemeral0/sandbox/at-client/pull-3048038-FreeBSD_32/phobos'
gmake: *** [posix.mak:297: unittest-release] Error 2

Issues:
1) how to get 32 bit libs installed on freebsd 11
2) why are the tests timing out rather than fast failing
3) why isn't it a clear failure

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

--- Comment #6 from Brad Roberts  ---
I wasn't thinking about this last night, but the behavior that's in question
isn't master or stable branch, but rather 2.068.2.  That compiler's behavior is
where things are going wrong.  The problem, as far as the auto-tester is
concerned, has been worked around sufficiently.  I'm not sure if there's any
remaining issues with the tip of tree builds.

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/0527f4eef35b56afd67c65382a0e395d86db93f4
issue 18515: Fix it so that neither g++ nor CC is required.

It was previously fixed so that cc is used if CC isn't set when
compiling dmd, but the test suite still had g++ hardcoded, so if the
system was set up with clang and not gcc, the dmd test suite barfed
midway through. This fixes it so that it uses c++ if CC isn't set
instead of using g++.

https://github.com/dlang/dmd/commit/bd2465510a172414cc626f7d7ebc3d0db8aece3f
Merge pull request #7949 from jmdavis/issue_18515

issue 18515: Fix it so that neither g++ nor CC is required.

--

[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #50 from Timothee Cour  ---
is this still being worked on ? IIRC calypso handles return by value of C/C++
correctly (via llvm), maybe some of implementation can be reused?

--

[Issue 16243] wrong C++ argument passing with empty struct when interfacing with Clang

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

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

--- Comment #20 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6966e6e0a9bf4ddf2760a46619e0c247ae8405ff
Temporary workaround for Issue 16243

https://github.com/dlang/dmd/commit/7969814467287d19726c81886c27e0692581092f
Merge pull request #7952 from WalterBright/workaround16243

Temporary workaround for Issue 16243

--

[Issue 16243] wrong C++ argument passing with empty struct when interfacing with Clang

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

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

--- Comment #19 from Walter Bright  ---
(In reply to Walter Bright from comment #18)
> Temporary workaround

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

--

[Issue 16243] wrong C++ argument passing with empty struct when interfacing with Clang

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

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

Walter Bright  changed:

   What|Removed |Added

Summary|wrong C++ argument passing  |wrong C++ argument passing
   |with empty struct and 6 |with empty struct when
   |integers|interfacing with Clang

--

[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

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

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

--- Comment #18 from Walter Bright  ---
Temporary workaround

--

[Issue 13855] Allow multiple selective imports from different modules in a single import statement

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||schvei...@yahoo.com
 Resolution|FIXED   |---

--- Comment #11 from Steven Schveighoffer  ---
Reverted (for now).

--

[Issue 1839] Give D a modern varargs system that allows forwarding

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

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

Martin Nowak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |WONTFIX

--- Comment #16 from Martin Nowak  ---
This won't work due to ABI specialities, things need to be setup for another
call and it's unreasonable that other backends would support our special D
vararg forward. Just get a va_list and forward that indead, it contains
pointers to all the original arguments.

--

[Issue 18518] New: use stable names for multilib object files (to enable incremental update of archives)

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

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

  Issue ID: 18518
   Summary: use stable names for multilib object files (to enable
incremental update of archives)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

At the moment the names for multilib objects are created based on a count.
https://github.com/dlang/dmd/blob/9691eba9441f7f165359716f80f46486ea09fb46/src/dmd/glue.d#L167

unicode_tables.o
unicode_tables_3a86_5f8.o
unicode_tables_3a87_521.o
unicode_tables_3a88_3a1.o
unicode_tables_3a89_62c.o

This means those names are not stable when using a different command line.
If we made the names unique based only on the primary symbol of that multilib
object, then we had a stable order that is invariant to modules order on the
command line.
This could then be used to incrementally update a multilib archive by
recompiling only modified modules.

--

[Issue 18517] New: Import order is not invariant

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

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

  Issue ID: 18517
   Summary: Import order is not invariant
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

Currently, compilation will change depending on the order that imports are
processed.  This order is determined by the order that modules are passed to
the compiler on the command line, and also the order they appear in each
individual file.  Here are some examples:

Import order in file changes output:

--- foo.d
version (A)
{
static import baz;
static import bar;
}
version (B)
{
static import bar;
static import baz;
}
void main()
{
import std.stdio;
writeln(bar.thing);
writeln(baz.thing);
}
--- bar.d
module baz;
enum thing = "this is baz from bar.d";
--- baz.d
module bar;
enum thing = "this is bar from baz.d";


dmd -version=A -run foo.d

this is bar from baz.d
this is bar from baz.d


dmd -version=B -run foo.d

this is baz from bar.d
this is baz from bar.d


Output changes depending on order of modules passed on the command line:

--- main.d
import ibar, ibaz;
void main()
{
ibarfunc();
ibazfunc();
}

--- ibar.d
import bar, std.stdio;
void ibarfunc()
{
writeln(thing);
}

--- ibaz.d
import baz, std.stdio;
void ibazfunc()
{
writeln(thing);
}

--- bar.d
module baz;
enum thing = "this is baz from bar.d";

--- baz.d
module bar;
enum thing = "this is bar from baz.d";


dmd ibar.d ibaz.d -run main.d
OUTPUT:
this is baz from bar.d
this is baz from bar.d

dmd ibaz.d ibar.d -run main.d
OUTPUT:
this is bar from baz.d
this is bar from baz.d

A PR to fix this has been submitted: https://github.com/dlang/dmd/pull/7900

--

[Issue 18244] Generic functions in std.math cannot be overloaded

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--

[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll

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

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

Martin Nowak  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Nowak  ---
Fixed by
https://github.com/dlang/installer/commit/d713fe32d9d031961d9cdaa23b8469b86a231117

--

[Issue 13855] Allow multiple selective imports from different modules in a single import statement

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

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

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/ddbdfb44379d4580d3ef0103834356f89d215566
Revert "fix Issue 13855 - multi-module selective import statements"

This reverts commit 05854166c7a67f27b33f5a5670d8956e738b4881.

https://github.com/dlang/dmd/commit/3955897f6e53a81adc0e77e2b559b2ae28fb5fa6
Merge pull request #7939 from wilzbach/revert-6589

Revert "fix Issue 13855 - multi-module selective import statements"
merged-on-behalf-of: unknown

--

[Issue 18468] cannot use `synchronized {}` in @safe code

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

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/8130ab0a5181e3a71442a7014ebc5159331a9d2e
Fix Issue 18468 - cannot use `synchronized {}` in @safe code

https://github.com/dlang/dmd/commit/f06b5ef86be01db8ca0b116bc5499a9d10e2a6a5
Merge pull request #7918 from wilzbach/fix-18468

Fix Issue 18468 - cannot use `synchronized {}` in @safe code
merged-on-behalf-of: Mike Franklin 

--

[Issue 18468] cannot use `synchronized {}` in @safe code

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

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

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

   What|Removed |Added

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

--

[Issue 18244] Generic functions in std.math cannot be overloaded

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

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a74271be4c93cf95905265597ac9bca426378f55
Revert "Issue 18244: std.math generic functions need to have sig constraints"

https://github.com/dlang/phobos/commit/230292aef0353efa25ba5e298c30cdf5ce6717b5
Merge pull request #6213 from dlang/revert-6040-signbit_sig

Revert "Issue 18244: std.math generic functions need to have sig constraints"
merged-on-behalf-of: Iain Buclaw 

--

[Issue 18341] Documentation for std.array.split is confusing/incorrect

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

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/1956daf34f8779779a1d393e1870e275a0619b2e
Fix Issue 18341 - Documentation for std.array.split is confusing/incorrect

https://github.com/dlang/phobos/commit/d487bec91f3e2505df99284cd6fbe669f26afa73
Merge pull request #6200 from wilzbach/fix-18341

Fix Issue 18341 - Documentation for std.array.split is confusing/incorrect
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18492] DLang STL links are broken

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

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/adf6113eb9f311acbd717d4c8b11c8f115892841
Fix Issue 18492 - DLang STL links are broken

https://github.com/dlang/phobos/commit/ae5e41d2081dcf1cc217116dcf4fd346a301289b
Merge pull request #6210 from wilzbach/fix-18492

Fix Issue 18492 - DLang STL links are broken
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18114] [Reg 2.078] regex performance regression

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

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/59520969ef73eaf0691972ee00b389e5bbc4c8fb
fix Issue 18114 - regex performance regression

- reduce copying of fat structs
- optimize layouts and opAssign of Captures

https://github.com/dlang/phobos/commit/460693c26f79a6aaa771ecdd42f791f4c3f5fb18
Merge pull request #5981 from MartinNowak/issue18114

fix Issue 18114 - regex performance regression
merged-on-behalf-of: Martin Nowak 

--

[Issue 18492] DLang STL links are broken

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

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

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

   What|Removed |Added

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

--

[Issue 18114] [Reg 2.078] regex performance regression

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

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

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

   What|Removed |Added

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

--

[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

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

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

--- Comment #17 from Walter Bright  ---
On Linux x86, given the code:

  struct S { };
  int test(S s, int a) { return a; }

g++ produces:
mov EAX,8[ESP]
ret

while clang++ produces:

mov EAX,4[ESP]
ret

This is with optimization on. With it off, the same problem.

--

[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

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

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

--- Comment #16 from Walter Bright  ---
With the upgrade to FreeBSD 11, this is now happening on 32 bit FreeBSD.

--

[Issue 18514] freebsd 11 with clang fails cpp abi tests

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Walter Bright  ---


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

--

[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

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

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

--- Comment #15 from Walter Bright  ---
*** Issue 18514 has been marked as a duplicate of this issue. ***

--

[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++

--

[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++

--

[Issue 18514] freebsd 11 with clang fails cpp abi tests

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++
 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
This appears to be caused by the switch from gcc to clang. The treatment of
structs with no fields is different.

--

[Issue 18505] delete deprecation message is misleading

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

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

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

   What|Removed |Added

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

--

[Issue 18505] delete deprecation message is misleading

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

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/db25160a7eeedb052cf6f2ed8de042cf129ebeeb
Fix Issue 18505 - delete deprecation message is misleading

https://github.com/dlang/dmd/commit/1834d62badb02c5f67d6d39e93c90e30df8412fc
Merge pull request #7947 from JinShil/fix_18505

Fix Issue 18505 - delete deprecation message is misleading

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

--- Comment #4 from Jonathan M Davis  ---
https://github.com/dlang/dmd/pull/7949

--

[Issue 18516] New: Add -vnrvo switch for showing user when nrv is done

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

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

  Issue ID: 18516
   Summary: Add -vnrvo switch for showing user when nrv is done
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

This optimization is practically undocumented, save for the glossary, and the
existing checks for NRVO in the D2 testsuite are really quite fragile as the
test for it is checking what is effectively undefined behaviour in normal
circumstances.

i.e:
What `p` is pointing to here is not known, as `tmp` is no longer in scope when
the assert() contract is executed.
---
static S* p;

S fn()
{
   S tmp;
   p = 
   return tmp;
}

S s = fn();
assert(p == );
---

So there's also a desire for a better way to test NRVO in the compiler, this
could be done by validating an AST dump of the backend codegen, but using the
existing TEST_OUTPUT support should be simpler.

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Yes, the dmd code:

https://github.com/dlang/dmd/blob/master/src/dmd/link.d#L420

shows that dmd is simply reading the CC environment variable. So it's something
else that is setting CC to gcc.

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

--- Comment #2 from Jonathan M Davis  ---
However, it does look like test/d_do_test.d hardcodes g++ if CC isn't set, so
that fails if g++ isn't available.

--

[Issue 18515] freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
Looking at the source code for the compiler, the only place I see that the CC
environment variable is used is in src/dmd/link.d, and it looks like back in
October, Martin changed it so that it uses cc if CC is not set, and if I have
neither gcc nor g++ in my PATH on my 64-bit FreeBSD system, it compiles just
fine. I know that that didn't used to be the case, but it appears to be so now
- presumably thanks to Martin's changes to link.d. So, I don't know why the
auto-tester would be trying to use gcc or g++. There is some logic in posix.mak
where it tries to figure out whether clang or gcc is being used - primarily so
that it can figure out which compiler flags to use, I think. Glancing over it,
it looks like it uses c++ --version to figure that out, though if HOST_CXX is
set, it uses that instead of c++, and it might use CXX if that's set. So, maybe
the problem with the auto-tester relates to the makefile somehow? Certainly,
from what I can tell, the issue is not as simple as dmd using gcc by default
now if CC isn't set.

Does the environment for the autoster have CC, CXX, HOST_CC, or HOST_CXX set to
gcc or g++?

--