https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109681
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
--- Comment #2 from Iain Buclaw ---
Fix to format hexstrings as big endian has been committed from upstream merge.
r14-9505
This should be resolved now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081
--- Comment #3 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> If I recall correctly, this trick is not guaranteed to work (for a
> drtbegin.o and drtend.o object), as there really no control over where in
> the TLS section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081
--- Comment #2 from Iain Buclaw ---
It could be moved to drtstuff.o to avoid it being in the library, but unless
there's an equivalent function available there'll be crashes caused by the GC
free'ing live objects as it did not scan all TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112290
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112285
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113758
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
--- Comment #6 from Iain Buclaw ---
(In reply to Richard Biener from comment #5)
> Unless gdc somehow guarantees bn->label and init are 128bit aligned
> then "casting" this way is broken. You can of course use
> build_aligned_type to build a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
--- Comment #4 from Iain Buclaw ---
Removed druntime dependency.
---
import gcc.builtins;
struct Token {
string label;
}
struct BreakStatement {
ulong pad;
Token label;
}
pragma(inline, false)
auto newclass()
{
void *p =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
--- Comment #1 from Iain Buclaw ---
Upstream is notified,
https://github.com/dlang/dmd/pull/16263#issuecomment-1969502776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #11 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #10)
> (In reply to Iain Buclaw from comment #8)
> > Created attachment 57329 [details]
> > The quick fix to the lock-free test
> >
> > The immediate thing that can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> Created attachment 57329 [details]
> The quick fix to the lock-free test
>
> The immediate thing that can be changed is turning the test into a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #8 from Iain Buclaw ---
Created attachment 57329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329=edit
The quick fix to the lock-free test
The immediate thing that can be changed is turning the test into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #7 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Buclaw from comment #4)
> > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
>
>
> > /* If it isn't always lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #4 from Iain Buclaw ---
Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
values one can get out of this built-in are "true" and "defer to run-time"
---
/* Return a one or zero if it can be determined that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #2 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #0)
> I am now seeing this on both Darwin and Linux BE powerpc.
>
> The message is somewhat odd, since AFAICS from the core druntime code that
> pulls in builtins.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #1 from Iain Buclaw ---
Isn't __atomic_is_lock_free tied to the __GCC_ATOMIC_XXX_T_LOCK_FREE macros?
: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
D ABI does callee destruction of arguments, which depends on the argument
already being copied to a temporary before passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #6 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Rainer Orth ---
> > I wonder how to handle this: while DejaGnu has an ucn effective-target
> > keyword,
> > the gdc.test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96347
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> I see in the olden days when D sat outside of GCC, this is what was done too.
>
> https://github.com/D-Programming-GDC/gdc/commit/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #8 from Iain Buclaw ---
Looking at C++ FE, I see they construct the string literal using
build_string (4, "foo")
because I can see the terminating 0 in the pretty-printed string.
---
unit-size
align:8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #7 from Iain Buclaw ---
(In reply to David Malcolm from comment #5)
> Is D correctly building that string_cst? Are D strings 0-terminated?
Yes, D strings are 0-terminated.
The way I've done it is, the string is constructed using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #2 from Iain Buclaw ---
(In reply to David Malcolm from comment #1)
> Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
> ./gdc -B. -S -fanalyzer oob.d
> I get:
> d21: error: cannot find source code for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
--- Comment #1 from Iain Buclaw ---
Reduced a bit more.
---
module object;
ref V require(K, V)(ref V[K] aa, K key, lazy V value);
struct Root
{
ulong[3] f;
}
Root[ulong] roots;
Root getRoot(int fd, ulong rootID)
{
return
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Roughly copied an example from the static analyzer talk and wrote it in D.
---
import core.stdc.string;
void main
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This code (translated from D to C++):
---
struct Guard {
int i;
~Guard() {}
};
Guard lock() {
return Guard();
}
void bar() {
auto foo = lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
--- Comment #3 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> I think some extra errors during the D front-end codegen pass are likely the
> most appropriate thing to do here, as you say, such things are rejected by
> C/C++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> this_2(D)->ap = VIEW_CONVERT_EXPR(ap_3(D));
>
> it looks odd since ap_3(D) is a is_gimple_reg but a struct[1] definitely
> would not. Maybe you are missing a
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Seen with gdc-12 with --enable-checking turned on, assume that it's going to
still be the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
issue.d:
---
import std.conv;
void main()
{
float* zis ;
static if (is(typeof(to!string(*zis
to!string(*zis);
}
---
std/conv.d:
---
T toStr(T, S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050
--- Comment #1 from Iain Buclaw ---
Doesn't even need to be a template that's imported. Two or more overloadable
functions will trigger the ICE as well.
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
ice.d:
---
import std : split;
---
std/package.d
---
module std;
public import std.array;
public import std.regex;
---
std/array.d
---
module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107749
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This got added during the conversion to Sphinx.
https://gcc.gnu.org/onlinedocs/gdc/
Now that experiment has been reverted, the link to from the main page to gdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #5 from Iain Buclaw ---
(In reply to Uroš Bizjak from comment #4)
> from:
> movl%esi, %ecx
> movl$1, %eax
> sall%cl, %eax
> testl %edi, %eax
> setne %al
> movzbl %al,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #2 from Iain Buclaw ---
Expected generated code would be:
---
bt32_setb*:
...
shrl$5, %edx
movl(%eax,%edx,4), %edx
xorl%eax, %eax
btl %ecx, %edx
setb%al
...
---
bt32_setae*:
...
shrl$5, %edx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #1 from Iain Buclaw ---
Non-pointer variants also not detected.
---
int bt32v_setb(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 != 0;
}
int bt64v_setb(const __UINT64_TYPE__ v,
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
int bt32_setb(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return ((p[bitnum >> 5] & (1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592
--- Comment #1 from Iain Buclaw ---
Generated function:
---
void foo (struct _param_0)
{
void label = <<< error >>>;
label:;
while (1)
{
{
struct thing;
thing = _param_0;
goto ;
}
goto ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> My builds are on Mac OS X 10.7/Darwin 11 still. What macOS version are
> you trying this on? FWIW, I gave up on 32-bit builds with macOS
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #1 from Iain Buclaw ---
Is there a (sort of simple) bootstrap process one can follow for 32-bit OSX?
I have the means to test locally, but I can't get much further than building
gdc-11 -m32 - using said compiler to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107552
--- Comment #1 from Iain Buclaw ---
Isn't this a duplicate of pr104749, which got fixed in 9.4.0?
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Seen when configuring with --target=aarch64-wrs-vxworks
Looking at config.gcc, aarch64*-*-* is not included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107241
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765
Iain Buclaw changed:
What|Removed |Added
CC||witold.baryluk+gcc at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107101
--- Comment #1 from Iain Buclaw ---
This also affects when compiling with `-nostdinc`.
: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Currently behaviour is that object.d is searched for anyway, resulting in an
error that it cannot be found.
---
/opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #25 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #24)
> I'd imagine all static asserts would be hit, so a lot more than that -
> floor, tan, sin, cos, pow, etc... - some of which are not exactly trivial to
> implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #24 from Iain Buclaw ---
(In reply to Peter Bergner from comment #22)
> (In reply to Peter Bergner from comment #21)
> > For the record, this is what I'm testing with:
>
> So we get farther, but ICE again at:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #12 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #11)
> Doesn't powerpc*-*-freebsd* use IEEE double long double?
> grep LONG_DOUBLE_SIZE *
> darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> linux64.h:#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #10 from Iain Buclaw ---
(In reply to Peter Bergner from comment #9)
> (In reply to Jakub Jelinek from comment #2)
> > Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the
> > only target that does:
> >
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Isolated, and translated to C from the D testsuite, likely can be reduced
further, as I don't think opCmpProper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106638
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106638
--- Comment #2 from Iain Buclaw ---
(In reply to Martin Liška from comment #1)
> Should likely lead to something like:
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
Indeed, I'm sure the wiki links were working at one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
When compiling with -O1 and above.
---
private struct _Complex(T) { T re; T im; }
enum __c_complex_double : _Complex!double;
pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765
--- Comment #6 from Iain Buclaw ---
r13-2002 (and r12-8673) is a start that sows the seeds to make the codegen
option -fno-weak-templates the default. Should just be a case of extending the
forced emission to all instantiations too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317
--- Comment #3 from Iain Buclaw ---
(In reply to Siarhei Siamashka from comment #2)
> I first tried to toggle "flag_weak_templates" in "gcc/d/lang.opt" from 1 to
> 0 in GDC11 instead of reverting PR99914, but the resulting toolchain was
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
Iain Buclaw changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
--- Comment #2 from Iain Buclaw ---
Looks like it's a middle-end missed-optimization, not a D front-end one.
https://godbolt.org/z/5WWYEG4jW
Perhaps we need an extra DCE pass?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Iain Buclaw changed:
What|Removed |Added
Known to fail||12.1.0
Known to work|
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Compiled with `gdc test.d` results in:
/usr/bin/ld: /tmp/ccxf3O8c.o: in function
`stdx.math.nextPow2!(ulong).nextPow2(const(ulong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
When compiled with: gdc -O2 empty.d ice.d
empty.d:
---
---
ice.d:
---
struct EnemyPool
{
int[] enemy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101691
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139
--- Comment #1 from Iain Buclaw ---
Note, gdc-11 and gdc-10 error as a result to a different issue.
---
cannot resolve type for cast(__vector(int[8]))arr
---
Fix was made in a newer version of upstream dmd, so that'll be handled in the
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Casting from vector to static array is permitted, and the frontend generates a
reinterpret cast, but casting back the other way results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105413
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942
Iain Buclaw changed:
What|Removed |Added
URL||https://github.com/dlang/dm
: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
---
void ice()
{
struct hasDtor
{
int i;
~this() { }
}
hasDtor[4] arr = hasDtor(4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659
--- Comment #2 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #1)
> If I recall the conversation correctly, either the CPU-specific D language
> hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and
> others.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659
--- Comment #1 from Iain Buclaw ---
If I recall the conversation correctly, either the CPU-specific D language
hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and
others. Or the tm_d file should be packed with a lot
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This was discussed in gcc-patches a while back, creating an issue for
tracking/fixing it.
---
g++ -fno-PIE -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104878
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105004
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
---
import core.stdc.config;
c_complex_float toNative(float re, float im)
{
return c_complex_float(re, im);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
Iain Buclaw changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #6 from Iain Buclaw ---
Created attachment 52649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52649=edit
fdump-tree-original
The corrupt is indeed coming from the front-end.
Attached tree dumps.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #5 from Iain Buclaw ---
(In reply to Rainer Orth from comment #4)
> typesem.s indeed shows small codegen differences, while for semantic3.s
> there are
> both codegen differences per se as well as label renamings that may not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #2 from Iain Buclaw ---
That's interesting. I've just done a build of
54ef95cc4d1f3f2cde7c1f13250f889ffb81ca75 (20220301) and I get the same
comparison failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104745
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104742
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104835
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 677 matches
Mail list logo
