[Bug d/90603] ICE in functionParameters, at d/dmd/expression.c:1553

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90603

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272366.

[Bug d/90893] ODR violation

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893

--- Comment #1 from Iain Buclaw  ---
libcall_type is internal to d/runtime.cc, so I'm fine with just prefixing it
with d_.

[Bug d/90863] ICE in StatementSemanticVisitor::visit, at d/dmd/statementsem.c:1992

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90863

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272352.

[Bug d/90559] Out of memory because of negative length

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90559

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Fixed in r272351

[Bug d/90560] ICE in visit, at d/dmd/dcast.c:1872

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90560

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Fixed in r272348

[Bug d/90762] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90762

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272347.

[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Iain Buclaw  ---
Fixed in r272340 and r272345

[Bug d/90761] ICE in visit, at d/dmd/dcast.c:883

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90761

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272346

[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iain Buclaw  ---
Fixed in r272344

[Bug d/90604] ICE in sizemask, at d/dmd/mtype.c:2542

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90604

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272343

[Bug d/90602] ICE: null field

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90602

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272342

[Bug d/90661] ICE in AlignDeclaration::syntaxCopy, at d/dmd/attrib.c:670

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90661

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272341

[Bug d/90660] ICE in TypeQualified::resolveHelper, at d/dmd/mtype.c:6738

2019-06-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90660

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r272339

[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524

2019-05-28 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651

--- Comment #2 from Iain Buclaw  ---
The second function is not necessary.


struct object {}
void f (...) {}

[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524

2019-05-28 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651

--- Comment #1 from Iain Buclaw  ---
Confirmed that segfault happens in upstream as well.

By the way, it would be interesting to see if any more problems can be found
just by prefixing all these generated tests with 'module object;' as the first
line - this makes it so there are no implicit runtime dependencies being
imported into the compilation.

[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552

2019-05-28 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650

--- Comment #2 from Iain Buclaw  ---
Related upstream bug, with fix (makes code an error).

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

[Bug d/90601] ICE: gimplification failed (gimplify.c at 13436)

2019-05-25 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90601

--- Comment #2 from Iain Buclaw  ---
(In reply to Richard Biener from comment #1)
> Well, fix_trunc_expr isn't an lvalue you can pre-increment ... if D means
> to pre-increment a temporary (and not a) then it has to say so explicitely.
> Note GENERIC doesn't allow floating types on {PRE,POST}{DE,IN}CREMENT_EXPR
> just in case D does.
> 
> A C compiler says the code is invalid C:
> 
> t.c: In function ‘f’:
> t.c:3:12: error: lvalue required as increment operand
>  return ++(a += 1.0);
> ^

This should be equivalent to '++(a += 1.0, a)'.  So just missing the getting
the lvalue out of 'a += 1.0' here, the post de/increment handler doesn't do
this unlike the binary assignment handler in the GENERIC builder visitor.

[Bug d/90560] ICE in visit, at d/dmd/dcast.c:1872

2019-05-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90560

--- Comment #1 from Iain Buclaw  ---
Reproducible in upstream dmd, bug raised here:
https://issues.dlang.org/show_bug.cgi?id=19890

[Bug d/90559] Out of memory because of negative length

2019-05-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90559

--- Comment #1 from Iain Buclaw  ---
This was fixed in upstream dmd, I'll backport the patch for 9.2.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

2019-05-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501

--- Comment #11 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #8)
> So the first question would be why D passes the return value as
> DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.

Looking at the places where DECL_BY_REFERENCE is set, this mismatch could
happen when the result should be returned using NRVO.

To memory, using a mixture of DECL_BY_REFERENCE and CALL_EXPR_RETURN_SLOT_OPT
gives a desired behaviour of eliding a copy.

Two things come to mind as alternatives:

1. Currently for NRVO, the DECL_RESULT is explicitly set as not addressable.

  TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
  DECL_BY_REFERENCE (resdecl) = 1;
  TREE_ADDRESSABLE (resdecl) = 0;

Is it allowed for the decl to be both DECL_BY_REFERENCE and TREE_ADDRESSABLE at
the same time?  Or will that just confuse things further.

  TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
  DECL_BY_REFERENCE (resdecl) = 1;
- TREE_ADDRESSABLE (resdecl) = 0;
+ if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
+   TREE_ADDRESSABLE (resdecl) = 0;


2. Redo handling of NRVO in the D front-end, to enforce a specific semantic for
trivial types that we want to elide a copy for.

i.e: Given,
---
S foo()
{
S result;
result.a = 3;
return result;
}

void test()
{
S s = foo();
}
---

Generate this explicitly as:
---
S* foo(S* hidden)
{
S result;
result.a = 3;
*hidden = result;
return hidden;
}

void test()
{
S tmp;
S s = *foo();
}
---

Obviously, that change would be a bit more involved on my side.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

2019-05-16 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gdcproject dot org

--- Comment #3 from Iain Buclaw  ---
Do you need a minimized test case?

[Bug d/88238] libphobos compile problems on Solaris 10

2019-05-14 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238

--- Comment #7 from Iain Buclaw  ---
On Thu, 9 May 2019 at 20:11, ro at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
>
> Rainer Orth  changed:
>
>What|Removed |Added
> 
>   Attachment #46309|0   |1
> is obsolete||
>
> --- Comment #6 from Rainer Orth  ---
> Created attachment 46331
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46331=edit
> Fix libphobos compilation on Solaris 10 (PR d/88238)
>
> Apart from a few cleanups and minor bug fixes, this patch adds to the previous
> version a workaround for the lack of dl_iterate_phdr in 64-bit Solaris 
> 10/SPARC
> libdl.  The function is missing simply due to a packaging mistake: it actually
> lives in ld.so.1, libdl.so.1 only being a filter on that.  Since one cannot
> link
> to ld.so.1 directly and getting at dl_iterate_phdr using dlsym fails due to
> another
> bug, I'm again using a libgdc_s.so.1 helper library which implements that
> filter.
>
> Since it uses a Solaris ld-specific linker map file, it can only be built with
> ld directly, not the linker gcc was configured with, and thus not with 
> libtool.
> The patch consists primarily of additions to 
> DRUNTIME_LIBRARIES_DL_ITERATE_PHDR
> to detect the situation, the mapfile and libdruntime/Makefile.am code to 
> create
> the helper lib.
>

Is a helper library really needed?  I think I'd prefer it to go in any
of the existing libraries already built instead of adding more things
to link in.

> It was tested on sparc-sun-solaris2.10 and sparc-sun-solaris2.11 and as in the
> x86 case, testsuite results between the two are now almost identical.
>

Nice.

[Bug d/90446] New: ICE: Segmentation fault in build_function_type at gcc/tree.c:8539

2019-05-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90446

Bug ID: 90446
   Summary: ICE: Segmentation fault in build_function_type at
gcc/tree.c:8539
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Only seen on msp430-elf, happens because LANG_HOOKS_TYPE_FOR_MODE is given a
PSImode for the BT_UNWINDWORD type, returning NULL, and later segfaults when
generating BT_FN_UNWINDWORD_PTR.

[Bug d/90445] New: internal compiler error: in d_build_c_type_nodes, at d/d-builtins.cc:783

2019-05-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90445

Bug ID: 90445
   Summary: internal compiler error: in d_build_c_type_nodes, at
d/d-builtins.cc:783
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Only seen on pdp11-aout target, happens because SIZE_TYPE is not matched (it's
"short unsigned int" on pdp11).

Should instead set signed_size_type_node from signed_type_for (size_type_node),
matching UINTMAX_TYPE instead for setting {u}intmax_type_node.

[Bug d/90444] New: internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121

2019-05-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90444

Bug ID: 90444
   Summary: internal compiler error: in d_init_builtins, at
d/d-builtins.cc:1121
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Some back-ends declare va_list as a struct with no name, which is currently
unhandled by build_frontend_type().

Configurations that have seen this on:

- mips64vr-elf
- mipsisa64r2el-elf
- mipsisa64sr71k-elf
- mipstx39-elf
- pdp11-aout
- visium-elf

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

2019-04-26 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432

--- Comment #10 from Iain Buclaw  ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to ibuclaw from comment #6)
> > Author: ibuclaw
> > Date: Wed Apr 24 18:57:36 2019
> > New Revision: 270554
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=270554=gcc=rev
> > Log:
> > libphobos: Fix FAIL phobos.exp/core.time on CentOS 5.11, Linux 2.6.18
> > 
> > Merges upstream druntime e03164b5.
> > 
> > Reviewed-on: https://github.com/dlang/druntime/pull/2581
> > 
> > libphobos/ChangeLog:
> > 
> > 2019-04-24  Iain Buclaw  
> > 
> > PR d/89432
> > * testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639):
> > New proc.
> > * testsuite/libphobos.druntime/druntime.exp: Add compiler flag
> > -fversion=Linux_Pre_2639 if target is linux_pre_2639.
> > * testsuite/libphobos.druntime_shared/druntime_shared.exp: Likewise.
> > 
> > Modified:
> > trunk/libphobos/ChangeLog
> > trunk/libphobos/libdruntime/MERGE
> > trunk/libphobos/libdruntime/core/time.d
> > trunk/libphobos/testsuite/lib/libphobos.exp
> > trunk/libphobos/testsuite/libphobos.druntime/druntime.exp
> > trunk/libphobos/testsuite/libphobos.druntime_shared/druntime_shared.exp
> 
> This part:
> 
> #include 
> #if !defined LINUX_VERSION_CODE || LINUX_VERSION_CODE <
> KERNEL_VERSION(2.6.39)
> #error Yes, it is.
> #endif
> 
> The KERNEL_VERSION macro expects three arguments, so commas should be used:
> 
> "KERNEL_VERSION(2,6,39)"
> 

Oops, that must have been a fat finger incident when I was switching between
2,6,39 and 4,19,0 to test the trigger.

[Bug d/90250] libphobos: segfault in runtime caused by unexpected GC of TLS data.

2019-04-25 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90250

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Done in r270576.

[Bug d/90250] New: libphobos: segfault in runtime caused by unexpected GC of TLS data.

2019-04-25 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90250

Bug ID: 90250
   Summary: libphobos: segfault in runtime caused by unexpected GC
of TLS data.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

The crash is only observed on non Linux/glibc systems.

Reason being because glibc puts the TLS area for each new thread at the
beginning of the newly created stack. Due to the way we detect the stack
bottom, we hoover up the TLS data along with what we think the stack is.

This is of course a dirty implementation detail, but explains why things don't
crash on GNU/Linux the way they are.

---
final class Class
{
// This gets triggered although the instance always stays referenced.
~this()
{
import core.stdc.stdlib;
abort();
}
}

Class obj;

static this()
{
obj = new Class;
}

static ~this()
{
// Free without destruction to avoid triggering abort()
import core.memory;
GC.free(cast(void*)obj);
}

void doit()
{
foreach (i; 0 .. 10_000)
new ubyte[](100_000);
}

void main()
{
import core.thread;
auto t = new Thread();
t.start();

// This triggers the GC that frees the still referenced Class instance.
doit();
}

[Bug d/90086] libphobos: warning: type and size of dynamic symbol `fiber_switchContext' are not defined

2019-04-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90086

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r270560.

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

2019-04-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Iain Buclaw  ---
Upstream druntime has been patched to assume that only CLOCK_MONOTONIC and
CLOCK_REALTIME exist on linux versions older than 2.6.39.

Applied the fix, as well as what I posted to r270554.

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

2019-04-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432

--- Comment #5 from Iain Buclaw  ---
Created attachment 46240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46240=edit
patch for pr89432

(In reply to Uroš Bizjak from comment #4)
> Created attachment 46182 [details]
> Proposed patch
> 
> Attached patch introduces DRUNTIME_OS_LINUX_PRE_2639 function that detects
> linux version < 2.6.39 and sets LINUX_PRE_2639_FLAG. However, as shown in
> the Comment #0, CentOS 5.11 (kernel 2.6.18) lacks several other clock types
> besides CLOCK_BOOTTIME, so the patch does not fix the failure for these
> older kernels.
> 
> I doubt it is worth pushing this any further, so I'll just attach the patch
> here for reference.

Now that the unit-test runner has been hauled out properly into dejagnu, I was
thinking of this being the better way.

[Bug d/88654] Hangs in libphobos testsuite

2019-04-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #0)
> 3) and, if libcurl isn't available, I think it would be better to skip the
> test as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is
> available and if it fails, don't even try to run the test

This has been done in r270545, nothing else left do here as far as I can see.

[Bug d/90065] Unaligned accesses on strict-alignment targets

2019-04-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065

--- Comment #2 from Iain Buclaw  ---
I have my suspicions that the following code will throw an unaligned access
error as well.

shared int var;
void main() {
  synchronized { var = 1; }
}


As synchronized statements are lowered to the following equivalent C.

static char __critsec64[48];
_d_criticalenter(& __critsec64);
var = 0;
_d_criticalexit(& __critsec64);


Just going off memory, but I don't think the artificial __critsec variable
would be suitably aligned for use as a pthread_mutex_t.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

2019-04-23 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89735

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Iain Buclaw  ---
Tests that were problematic on bigendian were fixed in r270523.

I can't see any more reported issues, so marking resolved.

[Bug d/88431] link errors on build

2019-04-23 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Iain Buclaw  ---
Fixed in r270531.

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

2019-04-23 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Iain Buclaw  ---
It ended up being a little more work, as the proposed patch had a bug in it. 
But it's now done in r270514.

[Bug d/90130] gdc.test/runnable/test12.d FAILs

2019-04-23 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
I think it should be done in r270485.

[Bug d/88431] link errors on build

2019-04-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431

--- Comment #3 from Iain Buclaw  ---
Added some debug prints in the boilerplate check.

configure:12017: Checking compiler boilerplate from: $CC -o conftest$ac_exeext
$CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5
configure:12018: module mod; extern(C) int main() { return 0; }
configure:12019: Boilerplate = d21: warning: command line option '-Wlogical-op'
is valid for C/C++/ObjC/ObjC++ but not for D
d21: error: cannot find source code for runtime library file 'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' for
installation instructions.
d21: note: config file: not found
import path[0] = /usr/include/d


So the D boilerplate in the initial test does not match the warnings in latter
tests.

This is the problem here.

[Bug d/88431] link errors on build

2019-04-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431

--- Comment #2 from Iain Buclaw  ---
(In reply to David Binderman from comment #1)
> This config line works fine:
> 
> ../trunk/configure --prefix=/home/dcb/gcc/results.266950 \
>   --disable-multilib \
>   --disable-werror \
>   --enable-checking=df,extra,fold,rtl,yes \
>   --enable-languages=d
> 
> so it looks like using -O3 in the top level Makefile causes trouble.

I see the following in the config.cache for libphobos:

lt_cv_prog_compiler_pic_works=${lt_cv_prog_compiler_pic_works=yes}
lt_cv_prog_compiler_pic_works_D=${lt_cv_prog_compiler_pic_works_D=no}


config.log:

configure:12414: checking if ./gcc/gdc -B./gcc/ PIC flag -fPIC works
configure:12432: ./gcc/gdc -B./gcc/ -c -nophoboslib -fno-moduleinfo -nostdinc
-g -O3 -march=native -Wlogical-op  -fPIC conftest.d >&5
d21: warning: command line option '-Wlogical-op' is valid for C/C++/ObjC/ObjC++
but not for D
configure:12436: $? = 0
configure:12449: result: no


It looks like -Wlogical-op is the culprit, not -O3.

This is the condition in configure:
---
if (exit $ac_status) && test -s "$ac_outfile"; then
  # The compiler can only warn and ignore the option if not recognized
  # So say no if there are warnings other than the usual output.
  $ECHO "$_lt_compiler_boilerplate" | $SED '/^$/d' >conftest.exp
  $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
  if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_cv_prog_compiler_pic_works_D=yes
  fi
fi

[Bug d/88238] libphobos compile problems on Solaris 10

2019-04-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238

--- Comment #1 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #0)
> 
> which allow libgdruntime.so and libgphobos.so to link on Solaris 11.3 without
> unresolved symbols, there are more on Solaris 10:
> 
> * 
>   symbol not found: backtrace 
> (libdruntime/.libs/libgdruntime.so)
>   symbol not found: backtrace_symbols_fd  
> (libdruntime/.libs/libgdruntime.so)
>   symbol not found: backtrace_symbols 
> (libdruntime/.libs/libgdruntime.so)
> 
>   Unlike Solaris 11, Solaris 10 lacks the backtrace functions in libc.  When
>   trying to use them, this failed because backtrace-supported.h wasn't found 
>   during configure.  This is due to an error in m4/druntime/libraries.m4
> which
>   tries to add to CPPFLAGS with +=, which of course the shell doesn't
> understand.
> 

Just saw this, I noticed this also when building on one of the BSDs, fixed in
r270377.


> * 
> 
>   symbol not found: dl_iterate_phdr   
> (libdruntime/.libs/libgdruntime.so)
> 
>   Unlike Solaris 11, dl_iterate_phdr support was only backported to a late
>   Solaris 10 update and even so only lives in libdl, not in libc.  Not yet
>   fixed.
> 

So does dlopen and dl_iterate_phdr live in separate libraries?  I would have
thought that DRUNTIME_LIBRARIES_DLOPEN would correctly add -ldl to the driver
spec file.


> *
> 
>   symbol not found: getprogname   
> (libdruntime/.libs/libgdruntime.so)
> 
>   Solaris 10 lacks getprogname or equivalent; for now I'm faking this by just
>   returning "a.out".
> 

There's the following function in rt/dmain2.d

extern (C) string[] rt_args();

Would the basename() of argv[0] be a suitable fallback?  Looking at illumos,
they use dlinfo(RTLD_SELF, RTLD_DI_ARGSINFO) and strrchr(argv0, '/').


> *
> symbol not found: posix_memalign   
> (src/.libs/libgphobos.so)
> 
>   Also missing from Solaris 10.  I've not yet checked what to do here.  One
>   might be able to use pagealign_alloc from gnulib instead?

If the OS version can be obtained from the compiler, same as FBSD_MAJOR, then
one option would be to provide posix_memalign internally in druntime.

extern(D) int posix_memalign(void** ptr, size_t alignment, size_t size)
{
  // ...
}

extern(D) so that it won't conflict with extern(C) function of the same name.

Though whether it is worth the effort, I'm not so sure.  As you've said that
Solaris10 will be removed before.

[Bug d/90064] InSituRegion lacks SPARC64 support

2019-04-21 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Merged in r270483.

[Bug d/90130] gdc.test/runnable/test12.d FAILs

2019-04-20 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130

--- Comment #1 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #0)
> The gdc.test/runnable/test12.d test FAILs on Solaris 11/SPARC with Robin's
> big-endian
> patches applied:
> 
> FAIL: gdc.test/runnable/test12.d -finline-functions -funittest -g  
> execution test
> 
> core.exception.AssertError@runnable/test12.d(630): Assertion failure
> 

-- snip --

> (gdb) p/x *(int *)
> $9 = 0x1020304
> 
> I don't fully see why yet, however all this strongly argues that this part of
> testcase is bogus: you cannot pass a struct to sprintf whose format string
> expects an int.

I'm not sure the reason for the test - there's no upstream bugzilla reference,
and it was added 10 years or so back in one big bulk import.

Rather than removing outright, I guess using *cast(int*) as you've been doing
in gdb is probably the path of least resistance.

[Bug d/89293] libphobos: core.atomic should have fallback for no atomic library

2019-04-20 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89293

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Dealt with in r270470.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

2019-04-18 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093

--- Comment #63 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.

That shouldn't be difficult, I've create PR d/90136 to keep track of that.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

2019-04-18 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gdcproject dot org

--- Comment #62 from Iain Buclaw  ---
(In reply to Bernd Edlinger from comment #55)
> But, how about that:
> 

The gcc.attribute module just reuses the UDA mechanism, the value after @ can
be any kind of compile-time evaluated tuple or literal.

So you can do instead. if it makes things much nicer for you.

static if (GNU_ARM_EABI_Unwinder)
enum personality_fn_attributes = attribute("target", ("general-regs-only"))
else
enum personality_fn_attributes = "";

@personality_fn_attributes
private _Unwind_Reason_Code __gdc_personality(...)

[Bug d/90136] [d] Merge UDAs between function prototype and definitions

2019-04-18 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136

Iain Buclaw  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/90136] New: [d] Merge UDAs between function prototype and definitions

2019-04-18 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136

Bug ID: 90136
   Summary: [d] Merge UDAs between function prototype and
definitions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

For two function declarations that have identical signatures (there's no
mismatched nothrow/pure/@nogc/...) any user defined attributes applied to one
should be merged with the other.

Given:

@("foo")
void bar(ref double[4]);

void bar(ref double[4] a)
{
foreach (ref b; a)
b += 42;
}


This is important for one use of the gcc.attribute module.

static if (GNU_ARM_EABI_Unwinder)
{
  @attribute("target", ("general-regs-only"))
  private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
  _Unwind_Exception_Class
exceptionClass,
  _Unwind_Exception* unwindHeader,
  _Unwind_Context* context);
}

[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong

2019-04-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Definitions added in r270372.  I made a couple of tweaks to the original patch
so that only mcontext_t and ucontext_t are public in the module, other than
that, applied as-is.

[Bug d/90062] SPARC stack alignment is wrong

2019-04-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Patch committed to r270372.

[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC

2019-04-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Should be done in r270372, reopen if it's still a problem.

[Bug d/90086] New: libphobos: warning: type and size of dynamic symbol `fiber_switchContext' are not defined

2019-04-14 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90086

Bug ID: 90086
   Summary: libphobos: warning: type and size of dynamic symbol
`fiber_switchContext' are not defined
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

FAIL: libphobos.druntime_shared/core/thread.d (test for excess errors)
Excess errors:
/usr/local/bin/ld: warning: type and size of dynamic symbol
`fiber_switchContext' are not defined


The lack of type or size directives also means the execution of the test
segfaults as well.

[Bug d/88039] gdc.test/compilable/ddoc12.d FAILs

2019-04-13 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gdcproject dot org

--- Comment #9 from Iain Buclaw  ---
This should have been resolved in r266933, however I don't have the ability to
close.

[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC

2019-04-13 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079

--- Comment #1 from Iain Buclaw  ---
Maybe we should be setting TRANSPARENT_AGGR_P afterall, then fixing the
internal signatures in rt.aaA to accept a void*.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Iain Buclaw  ---
Fixed in r270302.

I'll have a look through and create new issues for the failures related to
Solaris that don't have any relation to this pr.

[Bug d/90012] untranslateable placeholder in expressionsem.c

2019-04-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90012

--- Comment #3 from Iain Buclaw  ---
(In reply to Roland Illig from comment #2)
> Thank you for changing this so quickly. Will your change make it into the
> next translation round before the 9.1 release? That would be good because it
> would save be quite some work.

Running i.e: 'msgmerge -U fr.po gcc.pot` will remove all dmd texts from fr.po,
however I don't know who maintains this, or how updates get submitted to/from
the translation project.

[Bug d/90013] wrong quotes in diagnostics

2019-04-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90013

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
It was the fault of the pot generator (well me I guess) that these sources got
picked up in the first place.

They are no longer part of gcc.pot.  I don't know how this gets merged into
each individual .po, but they should not be present anymore.

[Bug d/90012] untranslateable placeholder in expressionsem.c

2019-04-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90012

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
It was the fault of the pot generator (well me I guess) that these sources got
picked up in the first place.

They are no longer part of gcc.pot.  I don't know how this gets merged into
each individual .po, but they should not be present anymore.

[Bug d/88150] Use sections_elf_shared.d on Solaris

2019-04-08 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150

--- Comment #10 from Iain Buclaw  ---
I've got a (horrible?) hack for getting tls_modid from Solaris.

Looking at dlinfo(RTLD_DI_LINKMAP):

https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/rtld/common/dlfcns.c#L1927-L1934

The lmp variable returned is originally an Rt_map*, layout is:
---
struct Rt_map
{
Link_map rt_public;
const char* rt_pathname;
c_ulong rt_padstart;
c_ulong rt_padimlen; 
c_ulong rt_msize;
uint rt_flags;
uint rt_flags1;
c_ulong rt_tlsmodid;
}
---

Let's do a little test...
---
case PT_TLS: // TLS segment
assert(!pdso._tlsSize); // is unique per DSO
static if (OS_Have_Dlpi_Tls_Modid)
{
pdso._tlsMod = info.dlpi_tls_modid;
pdso._tlsSize = phdr.p_memsz;
}
else version (Solaris)
{
Rt_map* map;
version (Shared)
dlinfo(handleForName(info.dlpi_name), RTLD_DI_LINKMAP, );
else
dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, );
pdso._tlsMod = map.rt_tlsmodid;
pdso._tlsSize = phdr.p_memsz;
}
else
{
pdso._tlsMod = 0;
pdso._tlsSize = 0;
}
break;
---

Inspecting this in gdb
---
(gdb) p map
$1 = (struct Rt_map *) 0xfedb001
(gdb) p *map
$2 = {rt_public = {l_addr = 4275896320, 
l_name = 0xfc0f02e4
"/mnt/build/i386-pc-solaris2.11/./libphobos/libdruntime/.libs/libgdruntime.so.76",
l_ld = 0xfedd00d4, l_next = 0xfedb0678, l_prev = 0xfef206c8, l_refname = 0x0}, 
  rt_pathname = 0xfc0f0334
"/mnt/build/i386-pc-solaris2.11/libphobos/libdruntime/.libs/libgdruntime.so.76.0.3",
rt_padstart = 4275896320, rt_padimlen = 1272912, rt_msize = 1272912, rt_flags =
272761348, 
  rt_flags1 = 1155, rt_tlsmodid = 2}
---

And there it is, a valid rt_tlsmodid.

Interestingly, Solaris sets the first tlsmodid to zero.

https://github.com/illumos/illumos-gate/blob/8a06b3d6467c15646e663c05086378f16288af85/usr/src/cmd/sgs/rtld/common/tls.c#L52-L60

This is in stark contrast to what elf_shared expects, given that there's an
assert that it is always non-zero if _tlsSize is set.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-03 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #46060|0   |1
is obsolete||
  Attachment #46069|0   |1
is obsolete||
  Attachment #46077|0   |1
is obsolete||

--- Comment #15 from Iain Buclaw  ---
Created attachment 46086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46086=edit
patch for pr89255

Tracked down hang in std.net.curl module ctor/dtors inside version(unittest)
code are now added to test module info record.

Posting new patch with all so far.

[Bug d/89823] Composed message only partially translatable

2019-04-03 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
For now, translation is not required as of r270074.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-04-03 Thread ibuclaw at gdcproject dot org
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

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
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.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
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 name be sufficient?  And in which place?
> 

Actually, I'll just add a compilation flag that does nothing to the test.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-02 Thread ibuclaw at gdcproject dot org
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
> > Use dg-runtest instead of dg-test
> >
> > (In reply to Iain Buclaw from comment #4)
> >> (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> >> > 
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> >> > 
> >> > compilation is run 10 times in exactly the same way!?
> >> > 
> >> 
> >> Maybe something is missing in the part copied from 
> >> GCC_RUNTEST_PARALLELIZE. 
> >> I did see problems copying gcc_parallel_test_run_p and other procedures
> >> locally to the libphobos testsuite, it looked like it replaced itself
> >> incorrectly.
> >
> > Ahh, we're calling dg-test directly, instead of dg-runtest, so there's no
> > protection against parallelized tests.
> >
> > Looking at dejagnu/dg.exp, there's no reason to use dg-test, so switching 
> > all
> > over.
> 
> Yes, that worked fine, thanks.  However, looking at libphobos.sum now,
> there are still 3 tests that show up more than twice (once for each
> multilib):
> 
>   8 PASS: libphobos.cycles/mod1.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod1.d execution test
>   8 PASS: libphobos.cycles/mod2.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod2.d execution test
>   8 PASS: libphobos.cycles/mod3.d (test for excess errors)
>   8 PASS: libphobos.cycles/mod3.d execution test
> 
> The different compilations/executions should be distinguished somehow in
> the test names.

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 name be sufficient?  And in which place?


libphobos_load:
---
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print execution test
PASS: libphobos.cycles/mod1.d (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate execution test
---

libphobos-dg-test:
---
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=ignore execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=abort execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=print execution test
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate (test for excess errors)
PASS: libphobos.cycles/mod1.d --DRT-oncycle=deprecate execution test
---

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-01 Thread ibuclaw at gdcproject dot org
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 -fversion=Shared -shared-libphobos (test
> >> for excess errors)
> >> FAIL: ../src/std/socket.d -fversion=Shared -shared-libphobos (test for
> >> excess errors)
> >> FAIL: ../src/std/stdio.d -fversion=Shared -shared-libphobos (test for 
> >> excess
> >> errors)
> >> FAIL: ../src/std/stdio.d -fversion=Shared -shared-libphobos execution test
> >> 
> >> std.exception.ErrnoException@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/
> >> ../src/std/stdio.d(1028): Could not seek in file
> >> `/tmp/deleteme.dmd.unittest.pid16148-детка.stdio.d.1037' (Invalid argument)
> >> 
> >
> > There's no backtrace, so don't know which unittest it came from, what are 
> > the
> > reasons why fseeko may return invalid argument on Solaris?  Specifically
> > anything that differs from other implementations.
> 
> Off the top of my head, could be related to largefile handling (or lack
> thereof).

I've just spotted that the line number is conveniently part of the file name
(line 1037)

Looking at that unittest, it is indeed testing largefile handing.

---
version (CRuntime_DigitalMars)
auto bigOffset = int.max - 100;
else version (CRuntime_Bionic)
auto bigOffset = int.max - 100;
else
auto bigOffset = cast(ulong) int.max + 100;
f.seek(bigOffset);
assert(f.tell == bigOffset, text(f.tell));
---

And subsequently finding this documentation:
https://docs.oracle.com/cd/E37069_01/html/E54439/fseeko64-3f.html

fseeko64 and ftello64 operate identically to fseek and ftell respectively,
except that the first two routines will operate on "large files" as well --
files with size in bytes greater than the range of INTEGER*4 data (2 Gb). Large
file support was introduced with the Solaris 2.6 operating environment.


In the druntime bindings there's only glibc that has large file support.

---
else version (Posix)
{
int   fseeko(FILE*, off_t, int);
off_t ftello(FILE*);
}
---

So its either fix the phobos test to use an offset less than 2GB on Solaris, or
add necessary fseeko64 definitions to druntime to use the large file functions
instead.  Probably the latter.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-01 Thread ibuclaw at gdcproject dot org
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.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-01 Thread ibuclaw at gdcproject dot org
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 r...@cebitec.uni-bielefeld.de from comment #3)
> > 
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> > 
> > compilation is run 10 times in exactly the same way!?
> > 
> 
> Maybe something is missing in the part copied from GCC_RUNTEST_PARALLELIZE. 
> I did see problems copying gcc_parallel_test_run_p and other procedures
> locally to the libphobos testsuite, it looked like it replaced itself
> incorrectly.

Ahh, we're calling dg-test directly, instead of dg-runtest, so there's no
protection against parallelized tests.

Looking at dejagnu/dg.exp, there's no reason to use dg-test, so switching all
over.

[Bug d/88462] All D execution tests FAIL on Solaris/SPARC

2019-04-01 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Iain Buclaw  ---
Commits r270043 and r270057 deals with the immediate problems here, other
problems raised in pr89255 I think should be handled on a per-case basis to
keep track off each fail test easier.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-01 Thread ibuclaw at gdcproject dot org
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 -shared-libphobos (test
> for excess errors)
> 
> Excess errors:
> /vol/gcc/bin/gld-2.32: warning: type and size of dynamic symbol
> `fiber_switchContext' are not defined
> 
> FAIL: ../libdruntime/core/thread.d -fversion=Shared -shared-libphobos
> execution test
> 

I saw that when checking -m32.  The linker gives the hint, the assembler
implementation of fiber_switchContext has neither type or size, and a segfault
occurs calling the function at run-time.  I added .type @function to resolve,
intended to push that later.

> WARNING: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution
> test program timed out.
> FAIL: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution test
> WARNING: ../src/std/parallelism.d -fversion=Shared -shared-libphobos
> execution test program timed out.
> FAIL: ../src/std/parallelism.d -fversion=Shared -shared-libphobos execution
> test
> 
> Those are PR d/89254, where the first had been fixed already in the old
> setup.  The std.parallelism one may be related to the fact that I'm
> running the bootstrap on an 8-socket system with 10 cores each and
> hyperthreading, i.e. 160 cores.
> 
> Those two are especially unfortunate since they hang indefinitely until
> I manually kill them, thus always require manual intervention.
> 

Are they not killed after the timeout?  I think it's 600 seconds by default.


> * On Solaris 11/x86, results are not too bad:
> 
>   === libphobos tests ===
> 
> 
> Running target unix
> FAIL: ../libdruntime/core/sync/mutex.d -fversion=Shared -shared-libphobos
> execution test
> 
> This one existed before:
> 
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /libdruntime/core/sync/mutex.d(381): unittest failure
> 

---
// Verify that the underlying implementation has been destroyed
// by checking that locking is not possible. This assumes
// that the underlying implementation is well behaved
// and makes the object non-lockable upon destruction.
// The Bionic and Musl C runtimes and DragonFly don't appear to do so, so skip
this test.
version (CRuntime_Bionic) {} else
version (CRuntime_Musl) {} else
version (DragonFlyBSD) {} else
assert(!mtx.tryLock_nothrow());
---

This is starting to look silly, but adding version (Solaris) to the growing
list may be required.


> FAIL: ../libdruntime/core/thread.d -fversion=Shared -shared-libphobos (test
> for excess errors)
> 
> Excess errors:
> warning: Text relocation remainsreferenced
> against symbol  offset  in file
> fiber_switchContext 0x4505  /var/tmp//ccYMWL0c.o
> fiber_switchContext 0x4b98  /var/tmp//ccYMWL0c.o
> 
> This code should be compiled with -fpic/-fPIC to avoid this.
> 

threadasm.S is already be compiled with -fPIC for the pic_object.  But not I
see for the non_pic_object unlike all *.d sources.  But it doesn't look like
it's the static library test that's failing here.

> FAIL: ../libdruntime/rt/minfo.d -fversion=Shared -shared-libphobos execution
> test
> 
> No indication in the logs what happened.
> 

More alignment woes with ModuleInfo?


> FAIL: ../src/std/base64.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> 
> Excess errors:
> ld: warning: symbol
> '_D3std8internal7cstring23__T11tempCStringTaTAyaZ11tempCStringFAyaZ3Res6__ini
> tZ' has differing sizes:
> (file /var/tmp//ccN7CxXc.o value=0x18; file
> /var/gcc/regression/trunk/11.5-gcc-gas/build/i386-pc-solaris2.11/libphobos/
> src/.libs/libgphobos.so value=0x108);
> /var/tmp//ccN7CxXc.o definition taken
> 
> There are several more testcases affected by this issue, all involving
> one of
> 
> std.internal.cstring.tempCString!(char,
> const(char)[]).tempCString(const(char)[]).Res
> std.internal.cstring.tempCString!(char,
> const(char)[]).tempCString(const(char)[]).Res
> std.internal.cstring.tempCString!(char,
> immutable(char)[]).tempCString(immutable(char)[]).Res
> std.internal.cstring.tempCString!(char,
> immutable(char)[]).tempCString(immutable(char)[]).Res
> std.internal.cstring.tempCString!(char,
> inout(char)[]).tempCString(inout(char)[]).Res
> std.internal.cstring.tempCString!(char,
> inout(char)[]).tempCString(inout(char)[]).Res
> 
> AFAIK there's no way to disable this warning.
> 

---
version (unittest)
{
// smaller size to trigger reallocations
enum buffLength = 16 / To.sizeof;
}
else
{
// production size
enum buffLength = 256 / To.sizeof;
}

To[buffLength] _buff;  // the 'small string optimization'
---

The library should not be doing that...


> FAIL: ../src/std/datetime/systime.d -fversion=Shared -shared-libphobos
> execution test
> 
> 

[Bug d/89255] libphobos.unittests multilib handling broken

2019-03-30 Thread ibuclaw at gdcproject dot org
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 commit.

[Bug d/89823] Composed message only partially translatable

2019-03-26 Thread ibuclaw at gdcproject dot org
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 array slice '%s', use pre-%s instead", s, 
> > exp->e1->toChars(), s);
> 
> The string "cannot post-%s …" will be extracted for translation, but the
> inserted words, "increment" and "decrement", will not.
> 
> At a minimum, these words need to be marked for translation too.  Better is
> probably to make it two complete messages.  For Swedish it would work to
> compose the sentence this way, but I suspect there are languages further
> removed from English where it would be hard.

The dmd sources should all be in the EXCLUDES file, I must have missed one when
grepping for the sources that have may emit an error.

[Bug d/89017] ICE in force_type_die, at dwarf2out.c:26061

2019-03-20 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Fixed in r269828.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

2019-03-16 Thread ibuclaw at gdcproject dot org
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 "make" after applying patch.  Then, I rebuilt application.  Could
> it be
> that full rebuild is needed?
> 
> Otherwise, maybe TYPE_ALIGN_UNIT (type) still yields 1.
> 

All modules would need rebuilding, so clean and rebuild the target libphobos
library too.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

2019-03-16 Thread ibuclaw at gdcproject dot org
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
> ../../../../gcc/libphobos/libdruntime/rt/minfo.d:259

[... snip ...]

> 
> and a few more.


Still all related to the same ModuleInfo generated by gdc compiler.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

2019-03-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89735

--- Comment #3 from Iain Buclaw  ---
Created attachment 45979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45979=edit
moduleinfo alignment

(In reply to John David Anglin from comment #2)
> Might add that there are quite a few unaligned accesses:

I guess that forcing the ModuleInfo type alignment to 1 is not helping (see
patch).

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

2019-03-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88724

--- Comment #3 from Iain Buclaw  ---
(In reply to dave.anglin from comment #2)
> On 2019-03-15 12:48 p.m., ibuclaw at gdcproject dot org wrote:
> > 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?
> I guess I could send headers for hpux11.11 to you privately.  They are not
> online.  The machine
> I use for testing isn't available for general access.  I could check around.
> 
> At the moment, I'm more concerned about the 32-bit test failures for d on
> linux.  For some reason,
> the test results on 64-bit hpux are way better on 32-bit linux or hpux:
> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg01307.html
> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg02011.html

That would be because of check_effective_target_d_runtime.  If false, then all
runnable tests would be demoted to compile-only.

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

2019-03-15 Thread ibuclaw at gdcproject dot org
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?

[Bug d/88990] ICE in get_symbol_decl, at d/decl.cc:1097

2019-03-15 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
Fixed in r269708.

[Bug d/88990] ICE in get_symbol_decl, at d/decl.cc:1097

2019-03-13 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990

--- Comment #1 from Iain Buclaw  ---
Doesn't look like invalid code, but 'extern' is propagated erroneously to all
declarations inside the block, even paraneters, which is why the ICE occurs.

[Bug d/88957] ICE: Segmentation fault in tree_could_trap_p, at tree-eh.c:2672

2019-03-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fixed in r269627.

[Bug d/87824] x86_64-linux multilib issues

2019-03-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #26 from Iain Buclaw  ---
I think r269625 was the last one to do in the list.

[Bug d/88958] ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887

2019-03-10 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
Fixed in r269557.

[Bug d/89041] ICE in get_frame_for_symbol, at d/d-codegen.cc:2175

2019-03-09 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89041

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r269533.

[Bug d/89016] ICE in ArrayLiteralExp::toStringExp, at d/dmd/expression.c:3873

2019-03-07 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89016

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
Fixed in r269465.

[Bug d/87824] x86_64-linux multilib issues

2019-02-21 Thread ibuclaw at gdcproject dot org
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.
> 
> (This is how libstdc++ testsuite determines correct include flags.)

Seems reasonable.

Filtering out flags not recognized by D would mean there's no need to touch
libstdc++.


# For the tests that mix C++ and D, need to know where headers are located.
set odir [lookfor_file ${gccpath} libstdc++-v3]
if { ${odir} != "" } {
set cxxflags [exec sh ${odir}/scripts/testsuite_flags --build-includes]
set idx [lsearch $cxxflags "-nostdinc++"]
append flags [lreplace $cxxflags $idx $idx]
}

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

2019-02-21 Thread ibuclaw at gdcproject dot org
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.

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

2019-02-21 Thread ibuclaw at gdcproject dot org
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)
> {
> version (Linux_Pre_2639) // skip CLOCK_BOOTTIME on older linux
> kernels
> return c != ClockType.second && c != ClockType.bootTime;
> else
> return c != ClockType.second; // second doesn't work with
> MonoTimeImpl
> 
> but it looks that Linux_Pre_2639 is not handled correctly. Depending on
> which kernel is considered the oldest supported kernel, version should also
> check for 2.6.28, 2.6.32 and 2.6.12:
> 

Linux_Pre_2639 is not an implicit version, and requires explicit detection and
adding '-fversion=Linux_Pre_2639' to GDCFLAGSX in the configure/testsuite
scripts.

[Bug d/88127] Many gdc.dg testsuite failures due to undefined reference to qsort_r

2019-02-18 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88127

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iain Buclaw  ---
This should be fixed now.

[Bug d/89293] New: libphobos: core.atomic should have fallback for no atomic library

2019-02-11 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89293

Bug ID: 89293
   Summary: libphobos: core.atomic should have fallback for no
atomic library
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Currently there's a static assert that fails if GNU_Have_LibAtomic is false.

In the absence of atomics, a statically allocated core.sync.mutex.Mutex could
be used instead to lock/unlock between operations, making sure there's no risk
of using it before D runtime has been initialized.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-02-10 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

--- Comment #1 from Iain Buclaw  ---
I'll use this PR as a reference to adding a compiler switch for building
modules in a "unittest runner" mode.  This to allow making it possible to build
all modules using dg-runtest without getting linker errors (as the modules
themselves exist in libphobos).

Currently, all modules are compiled with all unittests bundled into a
libgphobos_t.{so,a} test library before dejagnu kicks in.  The unittest runner
is just a thin wrapper around executing `./unittest` and then executing it
again in a loop, passing as an argument every module printed to stdout.

[Bug d/89254] std.net.curl and std.parallelism unittests hang

2019-02-10 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254

--- Comment #1 from Iain Buclaw  ---
I don't think you should be seeing a thread deadlock in std.net.curl after
r268746.

I've not been able to reproduce the never timing out part.  The process has
always been killed after 600 seconds.

[Bug d/88654] Hangs in libphobos testsuite

2019-02-10 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654

--- Comment #7 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #0)
> 
> 2) if Curl fails to initialize, the test shouldn't get stuck
> 

This part has been done in r268746.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-02-10 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Iain Buclaw  ---
Fix committed in r268740.

https://gcc.gnu.org/viewcvs/gcc?view=revision=268740

[Bug d/88958] ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887

2019-01-26 Thread ibuclaw at gdcproject dot org
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 callable using argument types ().
auto b = *  // b cannot be declared to be a function.

[Bug d/89042] ICE in visit, at d/decl.cc:597

2019-01-26 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89042

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Done in r268304

[Bug d/89054] libphobos/src/std/math.d:5279:18: error: undefined iden tifier 'ControlState'

2019-01-26 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89054

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
Phobos part of hppa support committed in r268293, build should be ok now.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-01-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989

--- Comment #5 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #4)
> ported to as many platforms as possible.  Then switch over to the D branch
> and be in lock-step with upstream dmd with regards to the latest
> implementation.

I mean, as of gdc 10, so version 9 becomes the baseline for bootstrapping
latter versions.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-01-24 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989

--- Comment #4 from Iain Buclaw  ---
(In reply to G. Steinmetz from comment #3)
> 
> Commit was from 2018-01-14, i.e. over a year ago.
> That makes me wonder, when will gdc be synchronized with dmd ?
> 

The main dmd branch has been converted over to D as of v2.069.  Whereas gdc is
a continuation of the old C++ branch, with new features and bug fixes converted
back to C++.  Its equivalence is v2.076, with a few extra regression patches.

Reason for staying with the C++ branch is so that gdc 9 release can be ported
to as many platforms as possible.  Then switch over to the D branch and be in
lock-step with upstream dmd with regards to the latest implementation.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-01-22 Thread ibuclaw at gdcproject dot org
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.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

2019-01-22 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989

--- Comment #1 from Iain Buclaw  ---
Thanks.

Out of curiosity, are you fuzz testing?

  1   2   >