https://bugzilla.gdcproject.org/show_bug.cgi?id=202
Johannes Pfau changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugzilla.gdcproject.org/show_bug.cgi?id=199
Johannes Pfau changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
https://bugzilla.gdcproject.org/show_bug.cgi?id=216
Johannes Pfau changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.gdcproject.org/show_bug.cgi?id=262
Bug ID: 262
Summary: Certain Druntime & Phobos unit tests are disabled
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: norm
On 29 June 2017 at 00:50, Mike via D.gnu wrote:
> On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
>> If that is the case, you should definitely compile with -fwhole-program.
>> I suspect that may cut down your compilation time by half or even more.
>
>
> If I only import __entrypoin
On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
Phase opt and generate is the topl-evel timer for the entire
"backend" compilation phase. I was expecting to see more of a
breakdown of individual passes.
Sorry, it didn't look broken down to me. Here's the full report.
arm-non
On 28 June 2017 at 23:15, Mike via D.gnu wrote:
> -
> The vast majority of time is spent in "phase opt and generate". A few
> observations:
>
> * Elapsed time isn't much different between -O3 and -O2 -finline-functions
> * -O
On Wednesday, 28 June 2017 at 16:52:26 UTC, Iain Buclaw wrote:
You probably want to tone down on optimizations as well. -O3
will be doing a lot of work, sometimes for little or no gain.
In most cases, -O2 -finline-functions is good enough, which can
be abbreviated further as simply -Os. [fo
On 28 June 2017 at 13:19, Mike via D.gnu wrote:
>
> PR507 eems to have made a mild improvement.
>
OK, so will pull it in. As what has already been said, if you aren't
doing already, always use --enable-checking=release, any other value
(apart from none) is for testing builds only.
You probably
On Wednesday, 28 June 2017 at 13:48:54 UTC, Johannes Pfau wrote:
I guess if archlinux GDC is slow as well this is unlikely the
main cause, but did you build your compiler in release mode
(--enable-checking=release)?
Thanks, I wasn't aware of that. I just rebuilt and it brought
the time down
Am Wed, 28 Jun 2017 12:56:40 +
schrieb Mike :
> On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
>
> > I'd be glad to do some troubleshooting if you have any ideas.
>
> I just checked in a branch that will compile with a desktop GDC
> compiler in case someone wants to give it a try
Am Wed, 28 Jun 2017 12:27:17 +
schrieb Mike :
> Does that indicate a backend problem? If you look at my previous
> post, linking was also quite high at 33s.
Probably. AFAIR -fsyntax-only includes all frontend processing so the
long runtime is likely due to the optimization phases, assemblin
On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
I'd be glad to do some troubleshooting if you have any ideas.
I just checked in a branch that will compile with a desktop GDC
compiler in case someone wants to give it a try. I tested with
6.2.1 20160830 from the Arch Linux repository.
On Wednesday, 28 June 2017 at 12:15:17 UTC, Johannes Pfau wrote:
Have you already tried -fsyntax-only to remove the backend
computation?
time arm-none-eabi-gdc -c -O3 -fsyntax-only -nophoboslib
-nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb
-mcpu=cortex-m4 -Isource/runtime -
On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
I'd be glad to do some troubleshooting if you have any ideas.
But I may not get to it right away as I will be traveling for a
few weeks.
Mike
Are we sure this is a frontend problem?
Have you already tried -fsyntax-only to remove the
On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:
Looks like it would be best to apply these PRs in the order
listed:
https://github.com/dlang/dmd/pull/5276
https://github.com/dlang/dmd/pull/5948
https://github.com/dlang/dmd/pull/6418
Compiling https://github.com/JinShil/stm32
16 matches
Mail list logo
