https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #3 from Iain Buclaw ---
Fix is trivial
--- a/gcc/d/dmd/dmodule.c
+++ b/gcc/d/dmd/dmodule.c
@@ -195,7 +195,7 @@ static void checkModFileAlias(OutBuffer *buf, OutBuffer
*dotmods,
const char *m = (*ms)[j];
const char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #6 from Iain Buclaw ---
Thanks, committed, and I'll apply it to gcc-10 and gcc-9 as well, as they have
the same condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 99337, which changed state.
Bug 99337 Summary: Sanitizer detect heap-buffer-overflow in checkModFileAlias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
Bug ID: 99466
Summary: internal compiler error: in
function_and_variable_visibility, at
ipa-visibility.c:795
Product: gcc
Version: 11.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
--- Comment #2 from Iain Buclaw ---
(In reply to Martin Liška from comment #1)
> What compiler options do you use?
No compiler options are necessary to reproduce the ICE. The symbol it fails on
is ___emutls_t.tlsvar.
Having a look at where this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
Iain Buclaw changed:
What|Removed |Added
Known to fail||8.4.0
--- Comment #3 from Iain Buclaw ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
--- Comment #5 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Iain Buclaw from comment #3)
> > Oldest compiler version have tried it one is 8.4.0, and there's an ICE there
> > as well.
>
> On Darwin16 : ICE back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691
--- Comment #1 from Iain Buclaw ---
Thanks, I have an OpenBSD VM with a WIP port as well, so I'll compare the two -
I don't recall any problems with shared libraries, though the host system
demands that PIC/PIE is forced for all built compilers/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #5 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #4)
> I tried to build gcc 10 snapshot 20210320 for Windows 64-bit with the
> proposed patch.
>
> First I got this error:
>
> make[2]: Entering directory
> '/R/winlibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #7 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #6)
> The patch for gcc/config/i386/t-cygming added a line:
> winnt-d.o: config/winnt-d.c
> I changed it to:
> winnt-d.o: config/i386/winnt-d.c
>
> Then I got one step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #9 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #8)
> predefs GNU D_Version2 LittleEndian GNU_SEH_Exceptions GNU_EMUTLS
> GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC assert D_ModuleInfo
> D_Exceptions D_TypeInfo a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #11 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #10)
> I thought MinGW-w64 is it's own C library.
> It is found by GCC build process because the folder mingw exists in the
> location specified with --with-build-sysro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794
Bug ID: 99794
Summary: libphobos: Support building on *-*mingw*
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
Bug ID: 99914
Summary: d: Template symbols not overridable by normal symbols
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917
--- Comment #1 from Iain Buclaw ---
(In reply to David Binderman from comment #0)
> trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not
> closed by va_end(). [va_end_missing]
>
> Source code is
>
> va_list ap;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 99917, which changed state.
Bug 99917 Summary: gcc/d/dmd/mtype.c:5223: missing call to va_end ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99812
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100062
Bug ID: 100062
Summary: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on
comdat
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
--- Comment #4 from Iain Buclaw ---
Weak declarations (both functions and variables) were found not to be working
at all on MinGW targets. The only way that there desired behaviour can be
achieved there then is to mark *all* declarations with ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100062
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> Since you say this happens on a DSO level why is this not achieved via some
> additional object at link-time (like crt*.o)? It sounds like you place
> the CDTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
--- Comment #2 from Iain Buclaw ---
Reduced test:
---
void main() { writef!"%s"; }
---
Any error that deals with a symbol that has a formatting string in it will
trigger a segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584
--- Comment #2 from Iain Buclaw ---
Running all D torture tests on sparc-sun-solaris2.11 with the RUNTESTFLAGS
--target_board=unix\{,-m64\}", I don't see any failures that arise in any f the
supported tests now.
---
=== gdc Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #3 from Iain Buclaw ---
I haven't seen any failures as of r11-4466. So a regression cropped up over
the last couple days maybe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #4 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #3)
> I haven't seen any failures as of r11-4466. So a regression cropped up over
> the last couple days maybe?
Actually, make that r11-4555 being the last commit tested,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #5 from Iain Buclaw ---
Without doing any bisecting, r11-4572 looks very suspect for the cause of the
segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #6 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #5)
> Without doing any bisecting, r11-4572 looks very suspect for the cause of
> the segmentation fault.
Confirmed, that is the commit that caused the regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660
Bug ID: 97660
Summary: [11 Regression] ICE: Segmentation fault in
function_summary::get(cgraph_node*) since
r11-4587
Product: gcc
Version: 11.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660
--- Comment #1 from Iain Buclaw ---
The call statement being looked at by cgraph_edge::redirect_call_stmt_to_callee
is:
# .MEM = VDEF <.MEM>
_47 = __sync_val_compare_and_swap_8 (ptr_45, 0, new_node.0_46);
cgraph_node::get returns NULL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660
--- Comment #4 from Iain Buclaw ---
Suggested fix
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557691.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #7 from Iain Buclaw ---
Created attachment 49485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49485&action=edit
workaround pr97644
Current workaround I'm using locally for the time being is to call
thunk_info::process_early_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #9 from Iain Buclaw ---
(In reply to Jan Hubicka from comment #8)
> > Current workaround I'm using locally for the time being is to call
> > thunk_info::process_early_thunks if the particular branch where this ICE
> > happens is hit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #11 from Iain Buclaw ---
(In reply to Jan Hubicka from comment #10)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
> >
> > --- Comment #9 from Iain Buclaw ---
> > (In reply to Jan Hubicka from comment #8)
> > > > Current wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #1 from Iain Buclaw ---
(In reply to Alex from comment #0)
> This code:
>
> import std.stdio;
>
> ubyte sum(ubyte[] bytes)
> {
> ubyte result;
> foreach(x;bytes)
> result += x;
> return result;
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #1 from Iain Buclaw ---
It would be great if you can use dustmite to make a reduced test case,
preferably by reducing phobos as well so it's just a standalone test.
https://github.com/CyberShadow/DustMite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #2 from Iain Buclaw ---
I think it is this issue that is being hit:
https://issues.dlang.org/show_bug.cgi?id=18970
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #3 from Iain Buclaw ---
Upstream PR raised with related backports.
https://github.com/dlang/dmd/pull/11971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #3 from Iain Buclaw ---
(In reply to Alex from comment #2)
> I agree that the order of evaluation of operands is undefined and writing
> code that depends on that order would not be reliable. In this case it's the
> execution of the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #4 from Iain Buclaw ---
Might be a regression caused by the fix for PR96924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #5 from Iain Buclaw ---
(In reply to Alex from comment #2)
> The arithmetic equivalent would be for:
> X += 4/2
> To be produce:
> Immediate load Register with 4
> Add register with 4 in it to x
> Divide register with 4 in it by 2
> R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #5 from Iain Buclaw ---
(In reply to Alex from comment #4)
> Created attachment 49573 [details]
> dustmite reduced problem.
Your reduction seems to have instead found another segfault. :-)
https://issues.dlang.org/show_bug.cgi?id=21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889
Bug ID: 97889
Summary: d: OutOfMemoryError thrown when appending to an array
with a side effect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #9 from Iain Buclaw ---
Another related issue has been created in pr97889.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889
--- Comment #1 from Iain Buclaw ---
Things go wrong because there is a SAVE_EXPR on the result of the library
function call of (val ~= 7).
It ends up being compiled down to:
save = _d_arrayappendcTX (typeid(val), &val, 1),
*(save.ptr + sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025
Bug ID: 98025
Summary: [11 Regression][CET] libphobos: dub segfaults when
built with gdc 11
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98025
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
--- Comment #21 from Iain Buclaw ---
(In reply to Eric Gallager from comment #20)
> (In reply to CVS Commits from comment #19)
> > ChangeLog:
> >
> > PR d/87788
> > * configure.ac: Don't disable D for *-*-darwin*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058
Bug ID: 98058
Summary: libphobos: Support building on *-*-darwin*
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
Bug ID: 98067
Summary: [11 Regression] d: ICE in in force_decl_die, at
dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
Iain Buclaw changed:
What|Removed |Added
Blocks||98058
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
--- Comment #2 from Iain Buclaw ---
Backtrace:
0xaf0ca2 force_decl_die
../../gcc/dwarf2out.c:26197
0xae7bd6 force_decl_die
../../gcc/dwarf2out.c:26142
0xae7bd6 dwarf2out_imported_module_or_decl_1
../../gcc/dwarf2out.c:2680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
--- Comment #3 from Iain Buclaw ---
It looks like the regressing change was r11-5003.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87818
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
--- Comment #4 from Iain Buclaw ---
What fails is gen_decl_die()
---
case CONST_DECL:
─> if (!is_fortran () && !is_ada () && !is_dlang ())
{
/* The individual enumerators of an enum type get output when we output
the Dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
--- Comment #8 from Iain Buclaw ---
As a last resort I could just not emit D manifest constants as CONST_DECLs.
They are a nice-to-have from the debugger, but functionally equivalent to C
macros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> As a last resort I could just not emit D manifest constants as CONST_DECLs.
> They are a nice-to-have from the debugger, but functionally equivalent to C
> macros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277
Bug ID: 98277
Summary: d: ICE in gimplify_expr, at gimplify.c
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98277
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058
Bug 98058 depends on bug 98067, which changed state.
Bug 98067 Summary: [11 Regression] d: ICE in in force_decl_die, at
dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98427
Bug ID: 98427
Summary: d: ICE in assign_temp, at function.c:986
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98427
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
--- Comment #1 from Iain Buclaw ---
To be fair, C++ does the same as well. The problem is the inliner (though no
inlining occurs when using immintrin.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
--- Comment #8 from Iain Buclaw ---
(In reply to Guillaume Piolat from comment #6)
> I provide intel intrinsics API for D, these intrinsics (like in C++) allows
> to change the rounding mode, and about 200 other functions that depend on
> the rou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98806
Bug ID: 98806
Summary: libphobos: Resulting executables segfault on mipsel
architecture
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98806
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
--- Comment #3 from Iain Buclaw ---
(In reply to Andreas Schwab from comment #2)
> diff --git a/gcc/d/dmd/dmangle.c b/gcc/d/dmd/dmangle.c
> index f6eee52afbf..73d9ac5367f 100644
> --- a/gcc/d/dmd/dmangle.c
> +++ b/gcc/d/dmd/dmangle.c
> @@ -822,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910
--- Comment #5 from Iain Buclaw ---
(In reply to Rainer Orth from comment #2)
> Unfortunately, even with your patch Solaris bootstrap is still broken:
>
Sorry, I've just been a bit slow getting the second part in. The first part
was just what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
--- Comment #5 from Iain Buclaw ---
(In reply to Tor from comment #0)
> make -j 64
>
Never had an issue with parallel builds up to -j16. Won't have the hardware to
even attempt -j64 for another fortnight.
Minimal libtool support is in libphobo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
--- Comment #7 from Iain Buclaw ---
(In reply to Richard Biener from comment #3)
> /bin/sh: ../libtool: No such file or directory
>
> that's odd. What's your host operating system, in particular what shell
> is /bin/sh?
>
> You'd need to see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
--- Comment #8 from Iain Buclaw ---
(In reply to Tor from comment #6)
> Built with -j 256 on aarch64 Cavium Tx2 CN9980 nodes. Worked like a charm.
>
> Not sure why "dash" is ok, while "bash" is not!? Do you?
>
> I will set default shell to das
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100552
Bug ID: 100552
Summary: configure: 32208: Syntax error: Bad substitution
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324
--- Comment #9 from Iain Buclaw ---
Does configure succeed in all multilib subdirectories?
tail x86_64-linux-gnu/*/libphobos/config.log
x86_64-linux-gnu/libphobos/config.log
And if one doesn't, inspect it to see why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769
--- Comment #3 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #2)
> Hmm. It appears that using `import core.stdc.string : memcmp;` actually
> resolves the problem. It looks like my manually declaration of memcmp for
> some reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882
Bug ID: 100882
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935
Bug ID: 100935
Summary: d: T.alignof ignores explicit align(N) type alignment
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964
Bug ID: 100964
Summary: d: TypeInfo error when using slice copy on Structs
with -fno-rtti
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100967
Bug ID: 100967
Summary: d: ICE: Segmentation fault
(../../gcc/d/dmd/declaration.c:1258) with -fno-rtti
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100967
--- Comment #1 from Iain Buclaw ---
ice.d:4:7: internal compiler error: Segmentation fault
4 | aa[0] = 1;
| ^
0xe958af crash_signal
../../gcc/toplev.c:327
0x88d8b8 TypeInfoDeclaration::TypeInfoDeclaration(Type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999
Bug ID: 100999
Summary: d: foreach over a tuple doesn't work on 16-bit targets
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100967
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101127
Bug ID: 101127
Summary: d: Compile-time reflection for supported built-ins
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101127
--- Comment #1 from Iain Buclaw ---
There's the language hook LANG_HOOKS_BUILTIN_FUNCTION_EXT_SCOPE, which seems to
do what we want on the surface, but then there's a question over whether this
is to be correct.
---
// static condition is false
1 - 100 of 327 matches
Mail list logo
