https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #38 from Richard Biener ---
(In reply to Richard Earnshaw from comment #37)
> (In reply to rguent...@suse.de from comment #36)
>
> > Note that the only thing we have to do is fix points-to info, the TBAA
> > info should be correct a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #37 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #36)
> Note that the only thing we have to do is fix points-to info, the TBAA
> info should be correct and OK even when objects share location, so there's
> n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #36 from rguenther at suse dot de ---
On Mon, 25 Jul 2022, rearnsha at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
>
> --- Comment #35 from Richard Earnshaw ---
> > There's no union involved here t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #35 from Richard Earnshaw ---
> There's no union involved here though but a memcpy used in BitCast.
Agreed, but by creating a shared stack slot, the compiler is effectively
creating a union of its own, and I think that needs to be ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #34 from Richard Biener ---
(In reply to Richard Earnshaw from comment #33)
> I suspect there is still a question, though, as to whether it is safe in
> general for two objects with non-conflicting alias sets to share a stack
> slot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #33 from Richard Earnshaw ---
I suspect there is still a question, though, as to whether it is safe in
general for two objects with non-conflicting alias sets to share a stack slot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed|2022-07-04 00:00:00 |2022-07-22
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #30 from Richard Biener ---
(In reply to Richard Earnshaw from comment #29)
> Thanks for having a look, yes, I was at a loss to understand how that change
> (which is before the problematic hunk would be the cause of the problem. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #29 from Richard Earnshaw ---
Thanks for having a look, yes, I was at a loss to understand how that change
(which is before the problematic hunk would be the cause of the problem. It
looks like we can rule that change out as a real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #28 from Richard Biener ---
(In reply to Richard Earnshaw from comment #26)
> git bisect points to commit r11-9688 resolving the issue. Before that
> commit the ivopts pass generates:
>
> ivtmp.761_217 = (unsigned int) &au;
> _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #27 from Richard Earnshaw ---
BTW, compile flags for an arm-none-eabi compiler are:
cc1plus -march=armv7-a+fp -mfloat-abi=hard -O2 -quiet -mthumb -fno-short-enums
-fno-exceptions -fvisibility-inlines-hidden -fmath-errno -fmerge-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #25 from Richard Earnshaw ---
A quick status update.
I've managed to reduce the testcase to the latest attachment. The program is
heavily reduced (so some bits likely don't make much sense), but the test still
'passes' when compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Attachment #53276|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #23 from Jan Wassenberg ---
Thanks for having a look. For casting, we CopyBytes between the two
representations, which boils down to __builtin_memcpy
(https://github.com/google/highway/blob/master/hwy/base.h#L819). Is there some
othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #22 from Richard Earnshaw ---
I notice that the sources seem to do floating-point negation by casting values
to integers, xor-ing the sign bit and then casting the result back to a float.
This is exactly the sort of operation that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #21 from Richard Earnshaw ---
I've finally managed to reproduce the test failure (someone has turned off
emu128 in the sources I have).
Rebuilding the failing test with -fno-strict-aliasing causes the test to pass.
That strongly su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #20 from Mathieu Malaterre ---
The Debian package highway 0.17.0-9 is not build with neon option (aka ARM7=OFF
in cmake), the code build just fine and test suite run fine (-O1):
*
https://buildd.debian.org/status/fetch.php?pkg=highw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #19 from Richard Earnshaw ---
Hmm, I'm not sure that makes sense to me. AFAICT highway requires an Arm CPU
with Neon, but the default compiler flags that you posted (-mthumb
-march=armv7-a+fp) does not provide that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #18 from Mathieu Malaterre ---
The complete line to generate the *.ii file is:
```
% /usr/bin/g++ -DHWY_STATIC_DEFINE -I/home/malat/highway -O2 -fstrict-aliasing
-ggdb3 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden
-Wno-buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #17 from Richard Earnshaw ---
And what options are you passing to cmake?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #16 from Mathieu Malaterre ---
This is one is producing wrong code:
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/11/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #15 from Richard Earnshaw ---
What's the output of "gcc -v" for the failing compiler(s)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #14 from Mathieu Malaterre ---
@Richard
I've uploaded the generated *.ii files (-save-temps), as discussed with
upstream:
* https://github.com/google/highway/issues/776#issuecomment-1177864014
I do not know the codebase very well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #13 from Mathieu Malaterre ---
Created attachment 53277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53277&action=edit
gcc-12 -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Mathieu Malaterre changed:
What|Removed |Added
Attachment #53271|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #11 from Richard Earnshaw ---
Object files are no use to us. We need preprocessed source along with analysis
of what you think has gone wrong (my program crashes or prints the wrong number
is rarely enough). Also, please make sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #10 from Mathieu Malaterre ---
I did upload the bad (gcc-11) and the good (gcc-12) object files. Not sure if
this is what was expected. In any case let me know if you want to provide more
info.
% gdb -batch -ex "disassemble/rs _ZN3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #9 from Mathieu Malaterre ---
Created attachment 53271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53271&action=edit
object files compiled using gcc or gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #8 from Mathieu Malaterre ---
(In reply to Jan Wassenberg from comment #7)
> The easiest way to reduce the amount of code in the binary is to comment out
> from mul_test.cc all the HWY_EXPORT_AND_TEST_P except the one with
> TestAllM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #7 from Jan Wassenberg ---
The easiest way to reduce the amount of code in the binary is to comment out
from mul_test.cc all the HWY_EXPORT_AND_TEST_P except the one with
TestAllMulEven.
The actual miscompilation is probably happeni
33 matches
Mail list logo
