https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #23 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:61f5b3c59ed20438d7d9918d7a83d29a21097d4e
commit r15-791-g61f5b3c59ed20438d7d9918d7a83d29a21097d4e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #22 from Richard Biener ---
Yes! Testing a fix for
int foo (int) {}
int bar (int) {}
typedef int (*pred)(int);
int x, y;
pred A () { if (x) return foo; else return bar; }
pred B () { if (y) return foo; else return bar; }
int __at
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 #17 from Iain Sandoe ---
however, the opover.o mismatch is a symptom - rather than the cause.
If all the objects for the D FE are built by D, then that would tend to point
to miscompilation of something in common code (that is built
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 #15 from Richard Biener ---
Indeed with boostrap-O3 I can see
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/d/opover.o differs
since both have debug info with bootstrap-O3 the difference is only
-18: 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #14 from Iain Sandoe ---
(In reply to Richard Biener from comment #13)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Richard Biener from comment #8)
> > > I've pushed a fix for PR115137, it's likely this fixes also thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #13 from Richard Biener ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Richard Biener from comment #8)
> > I've pushed a fix for PR115137, it's likely this fixes also this bug.
>
> unfortunately, not; at least, on my f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #12 from Richard Biener ---
How do I reproduce this? I tried, on x86_64-linux an all-language bootstrap
using gdc-13 for the first stage and that succeeded. I'm now trying again
with gdc-12, just --enable-languages=d and an explici
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
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #9 from Iain Sandoe ---
(In reply to Richard Biener from comment #8)
> I've pushed a fix for PR115137, it's likely this fixes also this bug.
unfortunately, not; at least, on my fastest x86 machine (AVX512) - the fail is
the same (di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #8 from Richard Biener ---
I've pushed a fix for PR115137, it's likely this fixes also this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #7 from Iain Sandoe ---
additional notes:
1. jamming -std=c++11 into stage2 and 3 cxxflags did not make any difference (I
was wondering if some c++17 copy elision thing might have changed the number of
temporaries).
2. still there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-darwin |x86_64-darwin, x86_64-linux
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #5 from Andreas Schwab ---
Dup of PR115137?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #4 from Iain Sandoe ---
so I am comparing the output of compiling gcc/d/dmd/opover.d with the stage1
and stage2 compilers.
Using -fdump-tree-all.
the .005t.original outputs are the same
the .006t.gimple outputs already have differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #3 from Iain Sandoe ---
(In reply to rguent...@suse.de from comment #2)
> > Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org
> > :
> >
> > where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154
> >
> > At presen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #2 from rguenther at suse dot de ---
> Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
>
>Bug ID: 115138
> Summary: [15 Regression] Bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
25 matches
Mail list logo
