Re: GCC 4.9.4 + GDC-patch: internal compiler error in libphobos/src/std/math.d:8040:47

[Iain Buclaw via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 22:27:49 UTC, kdevel wrote:

I applied the head

   commit ce249d880969111384d17f744687e427c843f1d4
   Merge: 8a6b7a4 0e517e4
   Author: Eugene Wissner 
   Date:   Tue Apr 10 15:37:32 2018 +0200

   Merge pull request #647 from belka-ew/gdc-49up

   Merge branch gdc-5 into gdc-4.9

of branch gdc-4.9 on top of gcc-4.9.4 and got this error:

/bin/sh ../libtool --tag=D   --mode=compile 
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 
-g  -nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime 
-I ../libdruntime -I . -c -o std/net/curl.lo 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d
libtool: compile:  
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 -g 
-nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime 
-I ../libdruntime -I . -c 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d  -fPIC -fversion=Shared -o std/net/.libs/curl.o

/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/math.d:8040:47: 
internal compiler error: Speicherzugriffsfehler
 return cast(Unqual!T) (T(1) << bsr(val) + type);
   ^
0x9e3b0f crash_signal
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/toplev.c:337
0xeb7af0 htab_hash_string
   
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libiberty/hashtab.c:839

0x7bc0f7 external_ref_hasher::hash(external_ref const*)
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7510
0x7bc0f7 hash_tablexcallocator>::find_slot(external_ref const*, insert_option)

   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/hash-table.h:505
0x7bc0f7 lookup_external_ref
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7538
0x7bc19d optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7576
0x7bc1c8 optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7580
0x7bc5ed optimize_external_refs
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7630
0x7bc9a5 output_comp_unit
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:8816
0x7d7319 dwarf2out_finish
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:24301
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Is GCC 4.9 still maintained?



No, there is no man power nor incentive to maintain any prior 
versions of gcc where D is not an official frontend.


That means only gcc-9, and all future versions that will follow 
for will receive bug fixes for as long as they are supported in 
GCC's release cycle.

Re: Forward declaration inside Function block, no error?

[Neia Neutuladh via Digitalmars-d-learn]

On Sun, 06 Jan 2019 20:19:59 +, Rubn wrote:
> You can declare functions inside of functions in D. You weren't forward
> declare grow() in the module namespace, so much as you were forward
> declaring a new function grow.

Unfortunately, you can't do forward declarations for nested functions. If 
you could, that would be handy for mutual recursion:

void main()
{
int a(int i);
int b(int i)
{
if (i > 0) return a(i - 1);
return abs(i);
}
int a(int i)
{
if (i % 2 == 0) return b(i - 2);
return b(i - 1);
}
writeln(a(12));
}

Unfortunately, Error: declaration a is already defined

And omitting the forward declaration gets you: Error: undefined identifier 
a

Converting an integer to a string with std.format.

[Per Nordlöw via Digitalmars-d-learn]

When converting a single integer to a string is `formatValue` 
preferred over `formattedWrite` in terms of compilation and 
run-time performance?

Re: Forward declaration inside Function block, no error?

[Rubn via Digitalmars-d-learn]

On Sunday, 6 January 2019 at 18:38:44 UTC, Benjamin Thaut wrote:

Today I found a bug in my D code.


import std.stdio;

// Type your code here, or load an example.
void grow()
{
writeln("grow");
}

void someFunc(bool condition)
{
if(condition)
{
void grow();
}
}


I tried to call the grow function, but accidentially copied the 
return value alongside the function name. I was wondering why 
this code compiles without errors. the "void grow();" becomes a 
no-op. In my opinion this could should not compile. Am I 
missing something here?


Kind Regards
Benjamin Thaut


import std.stdio;

void grow()
{
writeln("grow");
}

void someFunc(bool condition)
{
if(condition)
{
void grow();
pragma(msg, grow.mangleof); // _D3app8someFuncFbZ4growMFZv
}
}

You can declare functions inside of functions in D. You weren't 
forward declare grow() in the module namespace, so much as you 
were forward declaring a new function grow.

Re: Getting error in dmd testsuite

[Thomas Mader via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 14:45:54 UTC, Thomas Mader wrote:
gcc does not create the symbol at all on NixOS. I already 
created an issue for NixOS: 
https://github.com/NixOS/nixpkgs/issues/28896


I am not supposed to ask here but maybe someone knows about 
problems with gcc?


I finally found out why the symbols are missing. See 
https://issues.dlang.org/show_bug.cgi?id=19553#c3

Re: 9999999999999999.0 - 9999999999999998.0

[Samir via Digitalmars-d-learn]

On Sunday, 6 January 2019 at 01:05:08 UTC, Adam D. Ruppe wrote:
That's because it is done at compile time, since both are 
compile-time constants. The compiler will evaluate it using the 
maximum precision available to the compiler, ignoring your 
request to cast it to double (which annoys some people who 
value predictability over precision btw). At different 
precisions, you get different results.


Thanks for that explanation, Adam!  Very helpful.

On Sunday, 6 January 2019 at 03:33:45 UTC, Jesse Phillips wrote:

Since you got your answer you may also like
http://dconf.org/2016/talks/clugston.html


Thank you for pointing out that talk, Jesse.  I will set aside 
some time to go through that!


Samir