https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95419
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119817
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119826
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119874
Iain Buclaw changed:
What|Removed |Added
Last reconfirmed||2025-04-20
Assignee|ibuclaw at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119874
Bug ID: 119874
Summary: d: Recognize user-defined prototypes of built-in
functions
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119826
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119817
Iain Buclaw changed:
What|Removed |Added
Last reconfirmed||2025-04-15
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119817
Bug ID: 119817
Summary: d: internal compiler error: in
dwarf2out_imported_module_or_decl, at
dwarf2out.cc:27676
Product: gcc
Version: 15.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119799
Bug ID: 119799
Summary: d: internal compiler error: in visit, at d/decl.cc:838
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119761
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119761
Bug ID: 119761
Summary: d: importC cannot find input file
'__importc_builtins.d'
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109023
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119758
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119758
Bug ID: 119758
Summary: d: -fonly= argument only matches when including full
relative path to the input file
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112290
--- Comment #5 from Iain Buclaw ---
*** Bug 112291 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112291
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112291
Iain Buclaw changed:
What|Removed |Added
Known to fail||13.3.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118309
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
--- Comment #2 from Iain Buclaw ---
@Christophe, I can only assume this is fixed, but have no way to test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
--- Comment #4 from Iain Buclaw ---
(In reply to Christophe Lyon from comment #3)
> (In reply to Iain Buclaw from comment #2)
> > @Christophe, I can only assume this is fixed, but have no way to test.
>
> It seems so, has the test been renamed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
Bug 117995 depends on bug 117832, which changed state.
Bug 117832 Summary: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 117002, which changed state.
Bug 117002 Summary: [13/14/15 Regression] lifetime.d: In function
‘_d_newclassT’: error: size of array element is not a multiple of its alignment
with -Warray-bounds and -O2
https://gcc.gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
--- Comment #6 from Iain Buclaw ---
So I'm currently thinking that perhaps this could be fixed my end.
At the definition of the type, set TYPE_ALIGN and TYPE_PACKED to 1, so it's
equivalent to:
class __attribute__((packed))
Foo
{
...
};
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
--- Comment #2 from Iain Buclaw ---
Gave a little test of this flag. Doesn't look like it will be able to replace
all the uses where `memset(0)` is currently generated in the D front-end.
It probably doesn't harm to have both this and `-ftrivia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
--- Comment #5 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #4)
> I'm going to call this a bug in the D front-end.
>
> https://godbolt.org/z/EYvcfE4aK
>
> extern(C++) class Foo {
> ubyte[4] not_multiple_of_8;
> }
>
> static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
--- Comment #4 from Iain Buclaw ---
I'm going to call this a bug in the D front-end.
https://godbolt.org/z/EYvcfE4aK
extern(C++) class Foo {
ubyte[4] not_multiple_of_8;
}
static assert(__traits(classInstanceAlignment, Foo) == 8);
static a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117621
Iain Buclaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117621
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117621
--- Comment #3 from Iain Buclaw ---
The last change that touched TYPE_PACKED between 12..13 was
r13-1104-gf4c3ce32fa54c1.
Could start there for a quick bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117621
--- Comment #2 from Iain Buclaw ---
Reduced test:
```
void test8847e()
{
auto foo()(inout int)
{
struct Bar {}
return inout(Bar)();
}
auto bar = foo(0);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117621
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Last reconfirmed|2025-03-09 00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
Iain Buclaw changed:
What|Removed |Added
URL||https://github.com/dlang/dm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #7 from Iain Buclaw ---
>From http://www.dsource.org/projects/dmd/changeset/259
The first setting of `const` to the result variable looks fine, as that's
against the parameter in the `out(result)` function, the result cannot be
chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #6 from Iain Buclaw ---
https://github.com/dlang/dmd/blob/4661fec6b792dcb22d66776fcdbe62ecb59667d1/compiler/src/dmd/funcsem.d#L2420-L2421
Introduced by.
https://issues.dlang.org/show_bug.cgi?id=3390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #5 from Iain Buclaw ---
Looking at where TREE_READONLY gets set in the front-end, it's likely
introduced by PR110514.
It does look as though the result variable incorrectly has `const` tagged
against it though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #4 from Iain Buclaw ---
The D front-end doesn't set TREE_STATIC on the `__result` variable, it's
gcc/gimplify.cc at this location:
```
/* If a const aggregate variable is being initialized, then it
should never be a lose to promo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #3 from Iain Buclaw ---
It's only in latter tree dump passes we see that in the "bad" code gen, the
`const struct __result` is in fact static data from gdc-12 onwards.
```
struct str (struct B & this)
{
static const struct __res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
--- Comment #2 from Iain Buclaw ---
Both gdc-11 and gdc-12 seem to produce the same tree structures from initial
dump.
```
struct toString ()
{
return = {.length=1, .ptr="1"};
}
void __invariant1 (const struct B & this)
{
return;
}
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119139
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116975
Iain Buclaw changed:
What|Removed |Added
Attachment #60637|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116975
--- Comment #1 from Iain Buclaw ---
Created attachment 60637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60637&action=edit
First attempt at PR116975
Making a stab at this. As it's done in toplevel Makefile.tpl, it generates
STAGExxx_GD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Bug 118802 depends on bug 116961, which changed state.
Bug 116961 Summary: [12/13/14 regression] Valgrind reports uninitialized memory
use in dstruct.d (dmd.dstruct._isZeroInit(dmd.expression.Expression))
https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #9 from Iain Buclaw ---
Valgrind is happy with the reduced test after patch applied.
$ valgrind ./gcc/d21 repro.d -quiet -dumpdir repro.o- -dumpbase repro.d
-dumpbase-ext .d -mtune=generic -march=x86-64 -version -fsyntax-only -o
/de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #8 from Iain Buclaw ---
Created attachment 60606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60606&action=edit
Patch in testing
@Sam, currently building with the attached patch, if you are able to confirm it
fixes PR118802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #7 from Iain Buclaw ---
Minimal test passes with gdc-11, fails from gdc-12 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #5 from Iain Buclaw ---
(In reply to Andrei Horodniceanu from comment #4)
> Sorry for the wait:
> -
> $ cat repro.d
> module object;
> struct Gcx
> {
> float thing = 0.0;
> }
Thanks, tweaked your test into:
```
module object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #6 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> (In reply to Sam James from comment #0)
> > When bootstrapping with some patches for improving Valgrind support (see
> > PR116947), I hit this:
> >
> > ==26778== Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #23 from Iain Buclaw ---
@Sam, I have a suspicion that this is related to PR116961.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118654
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #14 from Iain Buclaw ---
(In reply to Sam James from comment #13)
> Thanks Iain.
>
> Building stage0 with STAGE1_C{,XX}FLAGS="-O0" works. I'll try reproduce
> manually next.
At the bottom of the conservative/gc.d module (well, almos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #12 from Iain Buclaw ---
(In reply to Sam James from comment #1)
> The differences are odd.
>
> ```
> $ diffoscope
> ./work/build/stage2-x86_64-pc-linux-gnu/32/libphobos/libdruntime/core/
> internal/gc/impl/conservative/gc.o
> ./wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #25 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #23)
> (In reply to Iain Buclaw from comment #22)
> > pthis.msgBuf = buf;
> In D, this is an array copy assignment.
>
> I've tried lowering this to `foreach (i; 0 ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #23 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #22)
> pthis.msgBuf = buf;
In D, this is an array copy assignment.
I've tried lowering this to `foreach (i; 0 .. 100) msgBuf[i] = buf[i]`, but
that doesn't trigger t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #22 from Iain Buclaw ---
Reasonably small D code reduction.
---
struct sICE
{
void **vtbl;
char[100] msgBuf = '\0';
}
sICE* ctor(sICE* pthis)
{
char[100] buf = void;
pthis.msgBuf = buf;
return pthis;
}
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #19 from Iain Buclaw ---
Thanks Stefan.
I might be able to reduce the test if the reproducer works for me too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #14 from Iain Buclaw ---
The compiler itself doesn't depend on the phobos standard library part of
libphobos, only druntime. User applications would use Phobos however.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #12 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #11)
> Apparently MinGW-w64 dosn't like extern char** environ;
>
> To avoid this issue for now I commented out the following in
> gcc/cp/module.cc:
> extern char **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118654
Bug ID: 118654
Summary: d: getTargetInfo key "CET" not supported by this
implementation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #7 from Iain Buclaw ---
Not able to reproduce this in an s390x QEMU VM running Debian.
Version: 20250117 / r15-6997
Configure flags: --enable-languages=d --enable-libphobos
--with-libphobos-druntime-only --enable-multiarch --disabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118584
--- Comment #4 from Iain Buclaw ---
Looks like upstream added a new version path to the fiber module.
https://github.com/dlang/dmd/pull/16331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118584
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
Bug 116613 depends on bug 116632, which changed state.
Bug 116632 Summary: d_diagnostic_report_diagnostic and non-textual diagnostic
output formats (e.g. SARIF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116632
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116632
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545
Bug ID: 118545
Summary: d: Not all language options get a url in diagnostics
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434
--- Comment #6 from Iain Buclaw ---
@Rainer, I think I've found the cause for discrepancy, a use of size_t vs.
widest integer for pointer offsets.
Can you give this a test?
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -1499,7 +1499,7 @@ public:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116632
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #5 from Iain Buclaw ---
And what version of gdc is being used to bootstrap?
It might matter, as I've come across one instance where the compiler/runtime
interface for BigEndian got mismatched at some point during gcc-14 development
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249
--- Comment #5 from Iain Buclaw ---
My guess is, I missed a change to the TypeInfo_Class layout in D runtime.
ClassFlags got reduced from a uint to a ushort.
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=libphobos/libdruntime/object.d;h=710f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116373
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118449
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118438
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118448
Iain Buclaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
Iain Buclaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117832
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117701
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118449
--- Comment #4 from Iain Buclaw ---
This commit r15-6816-gdd3026f05111a0.
Which pulls in this change from upstream
https://github.com/dlang/dmd/pull/16971
However, I can still trigger the fault in custom_gc if I were to add +1 loop
iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118449
--- Comment #3 from Iain Buclaw ---
Speaking to the maintainer who's working on the new GC implementation for D.
Initial suspicion is with the custom_gc.d test file itself, rather than changes
within the runtime library.
The custom_gc is just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118449
--- Comment #2 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #1)
> I think the reported line number slightly off.
>
> Ran it with -fsanitize=alignment and got this.
>
> ../../../../libphobos/libdruntime/core/internal/gc/blockmeta.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118449
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
--- Comment #5 from Iain Buclaw ---
I suspect one of them might be this issue
https://github.com/dlang/dmd/issues/20688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
--- Comment #3 from Iain Buclaw ---
Changes made to the module itself.
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=libphobos/src/std/bitmanip.d;h=15211a3a98adab5ab2952bf801a350a5db76055c;hp=0993d34843fcf58b739372b86381cd96b1eff68f;hb=dd3026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
Iain Buclaw changed:
What|Removed |Added
Last reconfirmed||2025-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118309
--- Comment #1 from Iain Buclaw ---
It looks like the cause is early debug hooks being called before types are
complete.
My sense is that almost all calls to rest_of_{type,decl}_compilation during the
codegen pass in the D frontend are too earl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118309
Bug ID: 118309
Summary: d: Forward referenced enums missing type names in
debug info
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117707
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295
--- Comment #3 from Iain Buclaw ---
(In reply to Alexandre Oliva from comment #2)
> Ugh, it looks like D deviates from one of the fundamental assumptions behind
> the change, namely, that for each named source file, the compiler would
> attempt
1 - 100 of 199 matches
Mail list logo