https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87455
--- Comment #6 from Fanael ---
Any hope of getting this fixed in GCC 10? It should just be a matter of
removing Zen[12] from X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
Fanael changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
About a week ago GCC started to emit frame pointers even in presence of
-fomit-frame-pointer whenever there's a call to a function w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Fanael changed:
What|Removed |Added
Target|i686-w64-mingw32|i?86-*-*
--- Comment #3 from Fanael ---
Reprodu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
Fanael changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Fanael changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #10 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
--- Comment #4 from Fanael ---
(In reply to Vladimir Makarov from comment #1)
> But I am planning to fix it until end of June.
Any progress on this one? Patching GCC to use Satan^H^H^H^H^Hreload is a
workaround, but one I'd rather avoid if at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58924
Fanael changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58924
--- Comment #2 from Fanael ---
Er, 'operator<<(basic_ostream& os, const charT* x)', without the
r-value ref, of course.
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
The following PURE EVIL but legal code:
namespace foo { namespace std {} }
using namespace foo;
#include
causes the compiler to spew out lots
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
Target Milestone: ---
GCC by default enables -mtune-ctrl=sse_packed_single_insn_optimal on
-mtune=znver1, even though that microarchitecture doesn't like it for the same
reason In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87455
--- Comment #1 from Fanael ---
Assembly diff between the two:
--- /dev/fd/63 2018-09-27 17:59:06.120507763 +0200
+++ /dev/fd/62 2018-09-27 17:59:06.120507763 +0200
@@ -7,21 +7,21 @@
main:
.LFB5179:
.cfi_startproc
- movaps .LC0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87455
--- Comment #3 from Fanael ---
> May be we should remove xorps generation part.
If it were up to me, I'd keep to for BDVER[1234] only, because xorps is still
one byte shorted than either xorpd or pxor and is as fast there, and introduce
a separa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87455
--- Comment #5 from Fanael ---
Created attachment 44829
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44829&action=edit
WIP patch
> We already have TARGET_SSE_TYPELESS_STORES for stores, so perhaps we want
> something like typeless reg-r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
Bug #: 55493
Summary: [4.8 Regression] LTO always ICEs on i686-w64-mingw32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: majo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
--- Comment #1 from fanael4 at gmail dot com 2012-11-27 16:25:58 UTC ---
Forgot to mention:
4.7.2 - works
4.8.0 r193777 - fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
--- Comment #3 from Fanael 2013-01-09 14:19:09 UTC
---
(In reply to comment #2)
> Are you sure that you do not somehow pull in LTO objects from older releases?
Yes, happens even with -nostdlib, even on builds where I'm absolutely sure
t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
--- Comment #6 from Fanael 2013-01-16 18:15:25 UTC
---
Oh right. Works for me too. I should've tested it more thoroughly first.
Sorry for bothering you guys.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
Fanael changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
Target: i686-*-mingw32
When targeting i686-mingw32 all programs compiled with GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003
--- Comment #1 from Fanael ---
Note: I was compiling with -O2, so the line number may not be very indicative.
Should I post a backtrace of -O0?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #48 from Fanael ---
Is revision 209946 an attempt to fix this?
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
When compiling the following code with C++11 and -Wunused-but-set-parameter on
struct Foo {
Foo(void* x) : y{static_cast(x)} {}
char* y;
};
GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Fanael changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #16 from
24 matches
Mail list logo
