https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
So a big part of what's missing in druntime bindings is *any* declarations for
version(CRuntime_Newlib) targets. Though as I understand it, Cygwin is a bit
of a hybrid in that matter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408
--- Comment #5 from ibuclaw at gcc dot gnu.org ---
(In reply to Corinna from comment #4)
> I'm not sure what you mean with "hybrid".
Probably the wrong word to use, based on what I was told via gcc irc.
"""
the relationship of cygwin1.dll and new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
--- Comment #6 from ibuclaw at gcc dot gnu.org ---
I'll add it as a note to the deviations page.
https://gcc.gnu.org/onlinedocs/gdc/Missing-Features.html#Missing-Features
I'd actually forgotten about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #9 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #8)
> +
> +/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration SYM.
> + Set flags to reflect visibility that NODE will get in the objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #10 from ibuclaw at gcc dot gnu.org ---
Without using `->visible()` would be something like:
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -2559,10 +2561,17 @@ set_linkage_for_decl (tree decl)
void
set_visibility_for_decl (tree node,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Looks like a bad mismatch between C++ and D.
When C++ calls the method, it pushes one register. When D calls it, pushes
two.
Looks like the method itself returns the result in 2 registers as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #13 from ibuclaw at gcc dot gnu.org ---
Confirmed, D is doing NRVO return whereas C++ isn't.
gdc-11 codegen of the `visible` method:
---
struct Visibility visible (struct AggregateDeclaration * const this)
{
return = this->visibi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #20 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Andrew Pinski from comment #18)
> > > I think the visibility type is POD (assuming D has that concept)
>
> At least the front-end doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #21 from ibuclaw at gcc dot gnu.org ---
There is something about the Darwin ABI I'm just not getting from looking at
the front-end alone though:
C++ Darwin 32-bit calling a method that returns an 8 byte struct:
```
__Z4testP3Bar:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #22 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
Taken from a test Iain had sent me, and I've s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #24 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #23)
> So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> same as Linux).
I'm still yet to work out why D on 32-bit Darwin behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #26 from ibuclaw at gcc dot gnu.org ---
Comparing the D and C++ trees side by side.
At the point of `finish_function` for the ::vis() method, I see the following:
D: type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #29 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #27)
> great!
>
> we make more progress now - at least past libphobos configure:
>
> we now fail building druntime/core/atomic.d and I am not quite sure h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945
Bug ID: 108945
Summary: [13.0] d: vector float comparison doesn't result in 0
or -1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946
Bug ID: 108946
Summary: [13.0] d: Identity comparison of vectors not supported
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108962
Bug ID: 108962
Summary: d: Don't generate code that throws exceptions when
compiling with `-fno-exceptions'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109023
Bug ID: 109023
Summary: d: Add option to include imported modules in the
compilation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
Bug ID: 109108
Summary: d: Undefined reference to lambda in private enum
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109144
Bug ID: 109144
Summary: d: Closure fields don't get same alignment as local
variable
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102093
Bug ID: 102093
Summary: d: Add --enable-d-flags= configure option to libphobos
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102094
Bug ID: 102094
Summary: d: ICE in gimple_register_canonical_type_1, at
lto/lto-common.c:430
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102618
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ibuclaw at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673
Bug ID: 102673
Summary: [9 Regression] Wrong code with -O due to
adjust_cond_for_loop_until_wrap
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673
--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Since pr101145, the function this now happens in is
number_of_iterations_until_wrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673
--- Comment #2 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #0)
> Bisected, and the commit that changed behaviour was the fix for pr84648.
Commit was r9-4145.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #4 from i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167
Bug ID: 108167
Summary: d: internal compiler error: in binary_op, at
d/expr.cc:117
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544
--- Comment #2 from ibuclaw at gcc dot gnu.org ---
What version of glibc are you using?
Not encountered this myself from debian's gcc packages.
$ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-9 -c -x d -
2076
$ echo "pragma(msg, int(__VE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544
--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Ah, it's likely something even more fiendish than that.
What encodings are you using? (i.e: locale -a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544
--- Comment #8 from ibuclaw at gcc dot gnu.org ---
(In reply to Fabian Vogt from comment #6)
> I had a quick debugging session: The DMD lexer code doesn't really care
> about the size of the buffer and instead runs until it encounters either a 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544
--- Comment #10 from ibuclaw at gcc dot gnu.org ---
(In reply to Fabian Vogt from comment #9)
> (In reply to ibuclaw from comment #8)
> > (In reply to Fabian Vogt from comment #6)
> > > I had a quick debugging session: The DMD lexer code doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109144
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Version|11.0|12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #11 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #0)
> At present, still trying to figure out how to debug this further .. it's D
> so no preprocessed output - I guess will have to try tree dumps.
Dustmite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #16 from Iain Buclaw ---
(In reply to Richard Biener from comment #15)
> Note the opover.d compile doesn't even use -O3, so this is all extremely
> odd. It would somehow point at a miscompile of the stage2 compiler by
> the stage1 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #18 from Iain Buclaw ---
Reduction of opover.d
```
bool __setArrayAllocLength(size_t newLength)
{
import core.checkedint;
bool overflow;
addu(newLength,
addu(0, 0, overflow),
overflow);
return true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #19 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #18)
> Reduction of opover.d
> ```
> bool __setArrayAllocLength(size_t newLength)
> {
> import core.checkedint;
> bool overflow;
> addu(newLength,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #20 from Iain Buclaw ---
Stepping through both the stage1-gcc/gdc and stage2-gcc/gdc compilers, there is
an apparent divergence in behaviour at this point in gimplify.cc
6527│ /* Now that the LHS is gimplified, re-gimplify the RH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #21 from Iain Buclaw ---
Now doing a fair comparison:
Command:
g++-11 -std=c++11 \
-fno-PIE -c -O3 -g -fno-checking -DIN_GCC -fno-exceptions \
-fno-rtti -fasynchronous-unwind-tables \
-W -Wall -Wno-narrowing -Wwrite-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103578
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112270
Bug ID: 112270
Summary: ICE: in verify_gimple_in_seq on powerpc-darwin9
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112270
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Based on what I see here, this patch to core.cpuid should be sufficient to fix
loop and not introduce any change in existing behaviour.
---
--- a/druntime/src/core/cpuid.d
+++ b/druntime/src/cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Upstream PR https://github.com/dlang/dmd/pull/15778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Patch ready to apply to releases/gcc-13, and backports to gcc-12 and gcc-11.
Mainline will get this in the next upstream merge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Test case should deterministically crash when kernel.randomize_va_space=0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Reducing the std module down to the following always produces a crash in
dmd_aaGetRvalue when running debian/ubuntu pre-compiled gdc-13 under gdb.
---
struct Tid
{
MessageBox mbox;
}
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #6 from ibuclaw at gcc dot gnu.org ---
Full reduction without any imports.
---
class LUBench { }
void lup(ulong , ulong , int , int = 1)
{
new LUBench;
}
void lup_3200(ulong iters, ulong flops)
{
lup(iters, flops, 3200);
}
fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Same, but without any compiler errors.
This is reproducible in upstream dmd too.
dmd -lowmem -preview=dip1021 pr110113.d -o-
---
class LUBench { }
void lup(ulong , ulong , int , int = 1)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #2)
> Gimple dump:
> ---
> __vector(int[4]) rshift (__vector(int[4]) v)
> {
> __vector(int[4]) D.1795;
>
> _1 = VIEW_CONVERT_EXPR(v);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
--- Comment #4 from ibuclaw at gcc dot gnu.org ---
A shortcut to signed_or_unsigned_type_for for vector types seems reasonable
nonetheless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
Bug ID: 110359
Summary: d: Suboptimal codegen for __builtin_expect(cond,
false) since PR96435
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
Bug ID: 110406
Summary: d: Wrong code-gen returning POD structs by value
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> >structs have been set the wrong mode
>
> No, they don't have wrong mode, just the x86_64 backend is broken, see bug
> 102027 comment #7 specificall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #4 from ibuclaw at gcc dot gnu.org ---
It would be good if TYPE_MODE no longer had such a strong influence though. In
the meantime, I ought to restore behaviour to how it was in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #8 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Which itself is GCC 12+ regression too ...
>
> I filed that as PR 110407, let's see what the x86 bac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #9 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #8)
> So long as C and D agree with each other when it comes to POD types, it
> almost doesn't matter to me weather the back-end is following the wrong ABI.
Or w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #10 from ibuclaw at gcc dot gnu.org ---
Looking at an ICE in stage2 D compiler for i686-darwin17, I realized that it's
another facet of this issue.
// aggregate.d
import dsymbol;
extern (C++) class AggregateDeclaration : ScopeDsymbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-06-28
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #34 from ibuclaw at gcc dot gnu.org ---
I think this should be fixed now. I'll let @Iain Sandoe confirm, as there are
likely other fixes he has relating to the testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110471
Bug ID: 110471
Summary: d: Don't generate code that throws exceptions when
compiling with `-fno-exceptions'
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511
Bug ID: 110511
Summary: d: internal compiler error: in setValue, at
d/dmd/dinterpret.c:7013
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110471
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110514
Bug ID: 110514
Summary: d: accesses immutable arrays using constant index
still bounds checked
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110514
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516
--- Comment #2 from ibuclaw at gcc dot gnu.org ---
(In reply to Witold Baryluk from comment #0)
> I did not test volatileStore, but I would not be surprised it is also broken.
volatileStore is fine, because that expands to an assignment, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108962
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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 202 matches
Mail list logo
