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
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=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=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 #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 #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 #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 #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=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=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 #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
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=110712
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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=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=103578
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=110959
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=108962
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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=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=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
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
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=110471
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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
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=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=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=110406
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
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=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
--- 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=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 #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 #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 #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
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=110359
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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
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=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=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
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
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=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
--- 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
--- 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 #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 #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
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=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=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=109108
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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=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=108763
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|
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=108167
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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=108946
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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
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=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=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=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=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 #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 #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 #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:
1 - 100 of 127 matches
Mail list logo
