https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #3 from Iain Buclaw ibuclaw at gdcproject dot org ---
(In reply to jos...@codesourcery.com from comment #1)
On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
-D generate documentation
The driver needs
: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Marking as enhancement, as I'm sure that my situation is pretty unique (also
coming from a frontend maintained outside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217
--- Comment #5 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> Fixed the first case, and now there is a second.
>
> Again, can't reproduce using equivalent C++ with g++. This time however I
> have no idea why, as both look like
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Starting from this commit, I have been seeing segfaults in the D frontend.
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/var-tracking.c?r1=231897=231896=231897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217
--- Comment #1 from Iain Buclaw ---
I should also note that this only ever triggers using both: -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217
--- Comment #3 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> Fixed the first case, and now there is a second.
>
Triggers using -O2 -g -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217
--- Comment #2 from Iain Buclaw ---
Fixed the first case, and now there is a second.
Again, can't reproduce using equivalent C++ with g++. This time however I have
no idea why, as both look like they produce identical codegen on the surface.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71224
--- Comment #2 from Iain Buclaw ---
Created attachment 38541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38541=edit
Reduced test
Attaching complete minimal test, as the mechanically reduced test perhaps
removes a bit too much.
Needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71224
--- Comment #5 from Iain Buclaw ---
And thinking more about it, I don't think it even explains why this triggers
the warning:
---
if (nlength < pthis->length)
{
Array aggr = {pthis->length - nlength, pthis->ptr + nlength};
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71224
--- Comment #4 from Iain Buclaw ---
(In reply to Andrew Pinski from comment #3)
> I think the warning is correct and here is why:
> If we look at the final code which is produced on the tree level:
>
> _3 = pthis_2(D)->length;
> _4 = _3 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71224
--- Comment #1 from Iain Buclaw ---
Oh, and also happens if I move the pointer + length adjustment into the loop.
---
void setlength(Array* pthis, size_t nlength)
{
Array aggr = {.length=pthis->length, .ptr=pthis->ptr};
for (size_t key
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This probably is related to PR71177 and PR57199, but unlike them, this test
case doesn't have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71224
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
In the following minimal test built with: g++ -O2
---
#include
struct S
{
void* get()
{
return NULL;
}
~S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762
--- Comment #1 from Iain Buclaw ---
Backporting r217638 to gcc-4.9 fixes the problem too.
Allowing propagation of __cond60 and __cond59 comparisons into comparisons of
len elides the wrong optimization.
---
__cond60_9 = len_8(D) > 1;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #4 from Iain Buclaw ---
I've just managed to have a brief time to think about this and look at how the
generator currently works, I think the following should be doable, and should
work with only one change to handle the fix-up of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #5 from Iain Buclaw ---
> - The combined option should have all languages so that the diagnostic "is a
> valid option for ..." references the correct frontends.
Ah, no. Because then the --help text would show both. Scratch that
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Reduced test:
---
struct DArray
{
__SIZE_TYPE__ length;
int* ptr;
};
void foo35(DArray)
{
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81422
--- Comment #6 from Iain Buclaw ---
Confirmed, I can see that tests have started passing on my side. Thanks!
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Minimal test.
---
#include
struct Stest
{
int foo[5]; // Triggers NRVO return on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #2 from Iain Buclaw ---
A little bit of consistency?
This was found in another language where NRVO is consistency expected to
happen. Having a quick look at bug 58055, seems to suggest that front-end
should generate better codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #6 from Iain Buclaw ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Iain Buclaw from comment #4)
> > The generated code sets the address of the constructed variable the same the
> > as the return address, yet the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #4 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #3)
> NRVO in the middle-end is solely an optimization. If some FE requires
> something above that, then it needs to do it itself, C++ is an example of a
> FE that does
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Reduced test, triggered only if compiling with -fPIE and affects multiple
front-ends.
---
struct string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725
--- Comment #9 from Iain Buclaw ---
Confirmed on my side, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87825
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #14 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #13)
> bootstrap succeeded on x86_64-darwin16 --enable-languages=all for 265659.
>
> Shall we leave this PR open as a place to track getting D working on Darwin?
> .. or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87816
--- Comment #1 from Iain Buclaw ---
I've received patches here for aarch64.
https://github.com/D-Programming-GDC/GDC/pull/744
I'll push them in once tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #3 from Iain Buclaw ---
Thanks, I'm just going to try building it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #5 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Iain Buclaw from comment #3)
> > Thanks, I'm just going to try building it now.
>
> didn't get much further - kinda looks like something isn't working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #7 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Buclaw from comment #5)
> > (In reply to Iain Sandoe from comment #4)
> > > (In reply to Iain Buclaw from comment #3)
> > > > Thanks, I'm just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #8 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #6)
>
> hmm - isn't there a way to put it in the non-default category instead so
> that someone trying to make it work doesn't need to hack configure?
>
> and then just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87789
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #10 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Iain Buclaw from comment #3)
> > Thanks, I'm just going to try building it now.
>
> didn't get much further - kinda looks like something isn't working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87827
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #1 from Iain Buclaw ---
Is there another way to get a section in earlier versions of Solaris?
The alternative is to support a vagary of methods in order to determine loaded
modules at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #1 from Iain Buclaw ---
This is part of the dmd frontend which as no interaction with gcc. So
gcc_unreachable() can't be used here.
Sounds like some independent compatibility layer is required here instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #3 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #1)
> In i686-linux bootstrap/regtest, I see:
> === gdc tests ===
>
>
> Running target unix
> FAIL: runnable/cppa.d execution test
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #4 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #3)
> (In reply to Jakub Jelinek from comment #1)
> > FAIL: runnable/eh.d -O2 execution test
> > FAIL: runnable/eh.d -O2 -shared-libphobos execution test
>
> On x86,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #6 from Iain Buclaw ---
(In reply to Johannes Pfau from comment #5)
> Iain, is there a specific reason why we don't have i686 on the GDC/buildkite
> CI? We could simply run a QEMU/KVM VM on a x86_64 host for this.
>
> And when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #10 from Iain Buclaw ---
(In reply to Johannes Pfau from comment #9)
> Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767
Could you post that to gcc-patches?
Should probably get write after approval for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88038
--- Comment #2 from Iain Buclaw ---
Build log is when testing r265361 from a couple weeks back.
Looking at recent history, the assert has been removed from the function since
then.
I'll trigger a rebuild to see if its still happening.
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Seen when bootstrapping.
/buildkite/ubuntu-cross1/gcc/isl/isl_tab_pip.c: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw ---
> > I backported a fix from the D sources so it should no longer segfault at
> > least.
>
> It doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #5 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> Given that Solaris 10 support will be removed in GCC 10 and Solaris 11
> has no problem here, I guess dealing with this isn't worth the trouble:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #1 from Iain Buclaw ---
I backported a fix from the D sources so it should no longer segfault at least.
From what I can see, it should pick up the object.d source correctly.
-nostdinc -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw ---
> > This is part of the dmd frontend which as no interaction with gcc. So
> > gcc_unreachable() can't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88040
--- Comment #1 from Iain Buclaw ---
I don't suppose this could make use of the existing -fmodule-file= option,
which translates a module name to a different file path?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> I think I saw a duplicate somewhere - this is using real-time threads pinned
> to a single CPU but yield()ing in a spinning loop expecting to make progress.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
--- Comment #2 from Iain Buclaw ---
I thought that the test case looked familiar.
https://issues.dlang.org/show_bug.cgi?id=18057
I had fixed this before in the D implementation branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #19 from Iain Buclaw ---
On another look, (In reply to Iain Buclaw from comment #15)
> Still to do are:
>
> - runnable/cppa.d: (Remove struct __c_{u}long detection and tests)
> - runnable/eh.d: (Have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > pragma(msg, pthread_mutex_t.alignof);
> > pragma(msg, Mutex.alignof);
> > pragma(msg, Mutex.m_hndl.offsetof);
>
> I get
>
> 8u
> 4u
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #4 from Iain Buclaw ---
Stepping through the backtrace, I see the following at Thread.initLocks
(core/thread.d around line 1719).
---
__gshared align(Mutex.alignof) void[__traits(classInstanceSize, Mutex)][2]
_locks;
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #8 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Iain Buclaw ---
> >> 8, but that let the constructor already fail the first time through
> >> where _d_arraycopy checks that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #12 from Iain Buclaw ---
(In reply to Johannes Pfau from comment #10)
> I guess the proper fix to the alignment problem is using
> 'https://dlang.org/phobos/std_traits.html#classInstanceAlignment' (or rather
> the druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #6 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
>
> Unfortunately, this doesn't work: the first time through, _locks[0] was
> already 8-byte aligned and everything worked fine. This remained when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
--- Comment #1 from Iain Buclaw ---
Does it appear to be the correct alignment at compile-time?
This just prints the what the front-end determines. Not discounting these
values somehow change during translation to gcc trees.
---
import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88366
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #4 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw ---
> > (In reply to Rainer Orth from comment #0)
> >>
> >> The problem obviously is that the native assemblers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88038
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #15 from Iain Buclaw ---
Still to do are:
- runnable/cppa.d: (Remove struct __c_{u}long detection and tests)
- runnable/eh.d: (Have -fno-reorder-blocks-and-partitions default for D)
- runnable/nulltype.d (Set TYPE_TRANSPARENT_AGGR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #4 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #1 from Iain Buclaw ---
> > Thanks, I will write up a small documentation of how the sections modules
> > interacts with runtime -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #1 from Iain Buclaw ---
Thanks, I will write up a small documentation of how the sections modules
interacts with runtime - along with compiler support.
As its heavily dependent on compiler and object format, I'll move the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #1 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
>
> The problem obviously is that the native assemblers don't support UTF-8 in
> identifiers (and I bet there are other non-gas assemblers that don't either).
>
Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87816
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #3 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #0)
> The reason I'm filing this is that there are multiple issues:
>
> 1) what I'm worried about most is that the timeouts for tests don't work, it
> happens that some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #5 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #4)
>
> If the test doesn't fail if it fails to load libcurl (and doesn't get
> stuck), it is fine too.
> If it fails if it is missing, yeah, something like a tcl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #6 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #4)
>
> My i686-linux bootstraps are done through a couple of executable scripts in
> ~/hbin directory on x86_64-linux:
> for i in ~/hbin/*; do echo ===$i===; cat $i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89054
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89042
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
--- Comment #1 from Iain Buclaw ---
Thanks.
Out of curiosity, are you fuzz testing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
--- Comment #2 from Iain Buclaw ---
This is code that the front-end implementation accepts as valid code, but it
should be an error. Referencing f on is own does not automatically take the
address of it, e.g:
auto a = f;// f(int) is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #12 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > --- Comment #6 from Iain Buclaw ---
> > Created attachment 46069 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46069=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #14 from Iain Buclaw ---
Created attachment 46077
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46077=edit
Add libphobos_test_name var
I'll just post this before I retired.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #13 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #12)
>
> They differ by libphobos_run_args, not by compilation flags.
>
> Maybe I'm running these tests in a lazy way, but would appending the
> execution args to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823
--- Comment #1 from Iain Buclaw ---
(In reply to Göran Uddeborg from comment #0)
> In d/dmd/expressionsem.c there is this piece of code:
>
> > const char *s = exp->op == TOKplusplus ? "increment" : "decrement";
> > exp->error("cannot post-%s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 89823, which changed state.
Bug 89823 Summary: Composed message only partially translatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
Iain Buclaw changed:
What|Removed |Added
Attachment #46060|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #2 from Iain Buclaw ---
Created attachment 46060
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46060=edit
patch for pr89255
I posted this to gcc-patches in three parts, it would be good if you can test
it on solaris before I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #6 from Iain Buclaw ---
Created attachment 46069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46069=edit
Use dg-runtest instead of dg-test
(In reply to Iain Buclaw from comment #4)
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #7 from Iain Buclaw ---
Ignoring the test results, multilib handling seems to be working well for you
then?
I can create individual PRs for each failure later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #4 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
>
> * On Linux/x86_64, I see a few failures on i686:
>
> Running target unix/-m32
> FAIL: ../libdruntime/core/thread.d -fversion=Shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #8 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Iain Buclaw ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> >>
> >> FAIL: ../src/std/range/package.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88127
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432
--- Comment #2 from Iain Buclaw ---
Mostly likely check will be adding an HAVE_CLOCK_BOOTIME test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432
--- Comment #1 from Iain Buclaw ---
(In reply to Uroš Bizjak from comment #0)
> libphobos testing on x86_64 CentOS 5.11 fails a testcase:
>
>
> There is the following code in time.d:
>
> static bool clockSupported(ClockType c)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #22 from Iain Buclaw ---
(In reply to Uroš Bizjak from comment #20)
>
> I'd like to propose an alternative patch. The testsuite harness should
> simply ask libstdc++ for correct include paths, like in the to be attached
> patch.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89735
--- Comment #6 from Iain Buclaw ---
(In reply to John David Anglin from comment #5)
> There's also an unaligned accesses here:
>
> (gdb) bt
> #0 rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (this=...,
> cycleHandling=...) at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89735
--- Comment #8 from Iain Buclaw ---
(In reply to dave.anglin from comment #7)
> On 2019-03-16 1:10 p.m., ibuclaw at gdcproject dot org wrote:
> > Still all related to the same ModuleInfo generated by gdc compiler.
> I just did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88724
--- Comment #1 from Iain Buclaw ---
The system headers (stdlib.h, time.h, stdint.h, etc...) will need to be ported
to druntime, are these available anywhere?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89016
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 677 matches
Mail list logo
