https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #13 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #12)
> Can you try -fno-reorder-blocks-and-partition adding to the options?
> This would not be the first time this option caused issues with EH.
No joy with -fno-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #14 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Can you try -fno-reorder-blocks-and-partition adding to the options?
> > This would not be the first time th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #15 from Jeffrey Walton ---
It looks like -fno-strict-aliasing cleared the crash. This is bad because I
thought we did not violate aliasing rules.
Let me try to find it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #18 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #17)
> The other thing to try is -fstack-reuse=none.
No joy with -fstack-reuse=none. The crash is still present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #19 from Jeffrey Walton ---
Created attachment 53427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53427&action=edit
Test script to build library at -O2 with -fno-xxx
Test script to build library at -O2 with -fno-xxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #20 from Jeffrey Walton ---
Hi Andrew.
I went through the list of options that are enabled at -O2 from [1]. I built
the library with each option separately at "-DNDEBUG -g2 -O2 -fno-xxx".
Here is the list of suspects. I seem to rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #13 from Jeffrey Walton ---
Add a mee too. When using sanitizers, like -fsanitize=undefined, the compiler
driver is not adding the necessary libraries to link the program. Ugh...
https://github.com/weidai11/cryptopp/issues/1141#issue
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Hello,
This is a feature request.
For targets that support no-exec stacks, we need a warning when GCC generates
code or drives the linker with loss of no-exec stacks.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863
--- Comment #2 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #1)
> I think the warning needs to be implemented in the linker rather than in GCC
> because the linker is what decides if there are executable stacks are needed
> or
++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Hi Everyone,
We are trying to fix a compile problem Debian encountered on Sid [1,2]. The
machine is armhf, but I don't have access to it. Sid is using GCC 11, but I am
not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455
--- Comment #2 from Jeffrey Walton ---
(In reply to Richard Earnshaw from comment #1)
> What's the configuration of the compiler? Eg, the output of gcc -v
Thanks Richard. I set-up a Debian Qemu/Chroot for armhf. I can now duplicate
the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455
Jeffrey Walton changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Jeffrey Walt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #23 from Jeffrey Walton ---
(In reply to Peter Cordes from comment #22)
> [...]
> That instruction is useless and should never be used in asm except for
> code-alignment reasons (1 byte longer than MOVLPS, same length as MOVSD, all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
201 - 214 of 214 matches
Mail list logo
