http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Bug #: 54589
Summary: [missed-optimization] struct offset add should be
folded into address calculation
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592
Bug #: 54592
Summary: [4.8 Regression] [missed-optimization] Cannot fuse SSE
move and add together
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778
sgunderson at bigfoot dot com changed:
What|Removed |Added
CC||sgunderson at bigfoot dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
Bug #: 54593
Summary: [missed-optimization] Move from SSE to integer
register goes through the stack without -march=native
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
--- Comment #2 from sgunderson at bigfoot dot com 2012-09-15 16:38:34 UTC ---
Interesting. So it's a conscious choice that “generic” does this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
--- Comment #4 from sgunderson at bigfoot dot com 2012-09-15 16:54:28 UTC ---
I'm not sure if I understand the comment very well; it talks about Pentium 4,
but none of them run 64-bit code, do they?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
--- Comment #6 from sgunderson at bigfoot dot com 2012-09-15 20:28:02 UTC ---
Ah. So basically it hurts AMD enough (the opposite doesn't hit Intel enough)
that the choice was made to make it that way generic too. Well, as long as it's
a deliberate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #2 from sgunderson at bigfoot dot com 2012-09-17 09:18:16 UTC ---
FWIW, in my original code, func() is a part of a loop body (it keeps reading
values from src in a loop). It doesn't really change anything in the generated
code, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55155
Bug #: 55155
Summary: Autovectorization does not use unaligned loads/stores
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Hi,
Given I'm on gcc 4.8.1 (Debian 4.8.1-2). Given the following test program:
sesse@gruessi:~$ cat bextr-test.c
#include stdint.h
uint64_t
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Hi,
The GCC documentation
(http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html) claims
there should be such an intrinsic, added in gcc 4.7:
unsigned long long _bzhi_u64 (unsigned long long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #2 from sgunderson at bigfoot dot com ---
On Sat, Jun 15, 2013 at 04:33:14PM +, jakub at gcc dot gnu.org wrote:
The fix for the compiler is easy, but at least the AVX2 spec documents that
_bextr_u{32,64} intrinsics actually take
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #4 from sgunderson at bigfoot dot com ---
On Sat, Jun 15, 2013 at 05:10:57PM +, jakub at gcc dot gnu.org wrote:
If both start and length are constants, then it will be folded by the
compiler,
similarly if you use it inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #6 from sgunderson at bigfoot dot com ---
BZHI seems to have the same problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57624
--- Comment #2 from sgunderson at bigfoot dot com ---
Shouldn't really the documentation say so, then? The entire GCC manual seems to
make no note of this header at all, as far as I can see.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #8 from sgunderson at bigfoot dot com ---
I really did spot the BZHI problem in actual code; that's how I found out :-) I
rewrote it slightly and the problem disappeared, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #10 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:27:02PM +, jakub at gcc dot gnu.org wrote:
Then please provide preprocessed testcase for it (plus command line options).
Because I'm really curious how
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #11 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:32:18PM +, sgunderson at bigfoot dot com wrote:
Sorry, the code is a) not so easy to make public right now, and b) this
particular edit has been lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #12 from sgunderson at bigfoot dot com ---
Created attachment 30389
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30389action=edit
BZHI bug example (compile with g++-4.8 -O2 -mbmi2 -c foo.cc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #13 from sgunderson at bigfoot dot com ---
There. That ought to satisfy your curiosity. :-) I get:
sesse@gruessi:~/addie$ g++-4.8 -O2 -mbmi2 -c foo.cc
/tmp/ccX2oEfE.s: Assembler messages:
/tmp/ccX2oEfE.s:21: Error: operand size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
sgunderson at bigfoot dot com changed:
What|Removed |Added
CC||sgunderson at bigfoot dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #7 from sgunderson at bigfoot dot com ---
Wait, sorry, someone's already pointed that out. Ignore me, then...
I can at least confirm it still happens with GCC 4.8.1.
ReportedBy: sgunderson at bigfoot dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
--- Comment #2 from sgunderson at bigfoot dot com 2008-11-30 15:06 ---
OK, I looked at the source. The issue here seems to be that 4.4 likes to
compile this:
z3 = ((z3) * (- ((INT32) 16069)));
into this:
10 0.0403 : 805cc87: lea(%ecx,%ecx,4),%ebx
--- Comment #4 from sgunderson at bigfoot dot com 2008-11-30 20:32 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 04:23:31PM -, rguenth at gcc dot gnu dot org wrote:
Which tuning are you using? Try enabling -mtune=generic
--- Comment #6 from sgunderson at bigfoot dot com 2008-11-30 20:40 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 08:37:31PM -, rguenth at gcc dot gnu dot org wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org 2008
--- Comment #8 from sgunderson at bigfoot dot com 2008-11-30 21:19 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:04:07PM -, rguenth at gcc dot gnu dot org wrote:
Append -v to the command-line you use for compiling
--- Comment #9 from sgunderson at bigfoot dot com 2008-11-30 21:22 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:19:08PM -, sgunderson at bigfoot dot com wrote:
-mtune=generic still produces these long series of leas
--- Comment #11 from sgunderson at bigfoot dot com 2008-11-30 22:48 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:29:29PM -, rguenth at gcc dot gnu dot org wrote:
so it uses -mtune=i486 - this optimizes the multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
Bug #: 51513
Summary: [missed optimization] Only partially optimizes away
unreachable switch default case
Classification: Unclassified
Product: gcc
Version: 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
--- Comment #1 from sgunderson at bigfoot dot com 2011-12-12 10:54:16 UTC ---
Forgot this:
pannekake:~ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
Summary: __builtin_lrintf() becomes a library call, not an
cvtss2si instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
--- Comment #2 from sgunderson at bigfoot dot com 2011-03-16 12:03:40 UTC ---
But the lrintf() man page says explicitly that these functions cannot set
errno. Is this the man page being too glibc-specific, or something else?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
--- Comment #6 from sgunderson at bigfoot dot com 2011-03-16 22:59:53 UTC ---
(In reply to comment #5)
So, there's no glibc bug, but I don't think this makes a compelling case for
any particular gcc behavior. The implementation is gcc+glibc, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49583
Summary: Reloading stack operands in the wrong order, so needs
to insert fxch
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49583
--- Comment #3 from sgunderson at bigfoot dot com 2011-07-03 17:20:11 UTC ---
Hi,
My bug report was (as you can see in the title) not about the fstps/fld
sequence; it was about the extraneous fxch instructions. (My original code was
with -ffast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715
Summary: Could do more efficient unsigned-to-float to
conversions based on range information
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715
--- Comment #3 from sgunderson at bigfoot dot com 2011-07-12 15:19:51 UTC ---
Wow, answer in record time :-)
I don't know anything about GCC internals, so I can't comment much on the
patch; my only worry here is what would happen if you had
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
Summary: Unneccessary reload causes small size regression from
4.6.1
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
--- Comment #1 from sgunderson at bigfoot dot com 2011-07-27 11:38:57 UTC ---
(In reply to comment #0)
Of course, the _most_ efficient code sequence here would be doing the i = 0
before the memset, but I'm not sure if this is legal. However, eax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49872
Summary: Missed optimization: Could coalesce neighboring
memsets
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
--- Comment #2 from sgunderson at bigfoot dot com 2011-07-27 17:28:19 UTC ---
(In reply to comment #1)
Actually, thinking about it, the most efficient code sequence would be just
giving 4100 to memset instead of 4096, but that's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49872
--- Comment #2 from sgunderson at bigfoot dot com 2011-07-28 10:09:51 UTC ---
I'm not sure if I've seen exactly this construction in real-world code, but
I've certainly seen examples of the hybrid I sketched out (looking at one was
what motivated
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sgunderson at bigfoot dot com
GCC build triplet: i486-linux-gnu
GCC host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68282
sgunderson at bigfoot dot com changed:
What|Removed |Added
CC||sgunderson at bigfoot dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71993
--- Comment #2 from sgunderson at bigfoot dot com ---
Right.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
I'm trying to write a library that uses F16C instructions in certain places,
and since they're not really universally accessible (and ld.so hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71990
--- Comment #4 from sgunderson at bigfoot dot com ---
OK, so it would have to be a special kind of cloning, not the one you can do
yourself from code as of today?
As a user, I suppose there's no really good way of dealing with this currently
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
As the summary says. You just get:
lib.cc:4:1: error: Parameter to builtin not valid: f16c
Tested with:
gcc version 7.0.0 20160707 (experimental) [trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71990
--- Comment #2 from sgunderson at bigfoot dot com ---
Would pushing the mv automatically upwards into callers really help? There's
still no way that I can see to inline the function; I mean, pushing upwards is
what I've been trying to do here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79727
--- Comment #2 from sgunderson at bigfoot dot com ---
Wait, it can't do with a substring match? That wasn't clear at all from the
documentation, and it makes the default a lot more strict than I assumed. Some
of the regexes are rather strange
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
It seems that fallthrough comments are not properly parsed if they are followed
by a preprocessor statement. Minified test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79746
--- Comment #1 from sgunderson at bigfoot dot com ---
Actually this is interesting; this code (derived from the previous one)
compiles without warning in GCC 7.0 and Clang, but gives an error in GCC 6.3:
struct Base {
Base(const
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
This is a minified testcase of MySQL when trying to compile with a 7.0
snapshot:
atum17:~> /usr/lib/gcc-snapshot/bi
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
I can't get the supposed fallthrough comments (on
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) to work:
gcc version 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79746
--- Comment #6 from sgunderson at bigfoot dot com ---
Thanks. But I'm still curious; is the second code snippet well-formed or not?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
I'm trying to make MySQL compile with LTO. There are a lot of ODR violations
(which I'm trying to fix), but sometimes, the warnings are too vague to give
any real information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #2 from sgunderson at bigfoot dot com ---
Running with -fno-diagnostics-show-caret does not help any:
../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ One
Definition Rule [-Wodr]
../include/violite.h:288:0
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
It seems that if you forward-declare a class in one translation unit (and use
pointers to it), it will count as a different type for LTO detection purposes,
which
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
As the bug title says:
#include
#include
__attribute__((target("default")))
void foo(int x)
{
ass
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
Seemingly one can't ask for a template to be multiversioned:
template
__attribute__ ((target("default")))
void func(T *x) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #7 from sgunderson at bigfoot dot com ---
(In reply to Manuel López-Ibáñez from comment #6)
>> fts0pars.y:62:0: note: a field with different name is defined in another
>> translation unit
> Did you cut the above? It lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #9 from sgunderson at bigfoot dot com ---
(In reply to Manuel López-Ibáñez from comment #8)
> Actually, what would be more useful is to detect that the difference in type
> comes from S and point out where S has been de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #5 from sgunderson at bigfoot dot com ---
(In reply to Markus Trippelsdorf from comment #3)
> I don't see any bug, all relevant information is in the warnings.
My point is that all relevant information _isn't_ in the warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80858
--- Comment #2 from sgunderson at bigfoot dot com ---
Yes, I mean that the error message isn't clear (and it's basically the same
error message in 4.8, so no regression).
I don't think I understand the difficulties involved. Doesn't the error
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Using gcc version 7.1.0 (Debian 7.1.0-5) (but the error goes back to at least
4.8, and amazingly, also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80858
--- Comment #4 from sgunderson at bigfoot dot com ---
I think this should work as reduction:
struct Empty {
};
template
struct A
{
A =(const A&)
{
T t(3);
return *this;
}
};
c
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
When compiling MySQL with GCC 8.0.0 20170917, I get
In file included from ../include/my_byteorder.h:53:0,
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82269
sgunderson at bigfoot dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82269
--- Comment #4 from sgunderson at bigfoot dot com ---
This one is perhaps a better case:
../sql/parse_tree_column_attrs.h: In constructor
'PT_blob_type::PT_blob_type(Blob_type, const CHARSET_INFO*, bool)':
../sql/parse_tree_column_attrs.h:548:59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81980
--- Comment #1 from sgunderson at bigfoot dot com ---
Forgot to say: Also present in trunk r251306 and all the way back to at least
4.8.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
The following (reduced) code gives a warning if and only if I add -m32:
atum17:~> cat test.c
#include
char a;
void set_message(co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335
sgunderson at bigfoot dot com changed:
What|Removed |Added
CC||sgunderson at bigfoot dot
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
The following code works under GCC for -std=c++14, but breaks under -std=c++17:
#include
#include
int main(void)
{
std::map
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
I believe this is distinct from #82593, so I'm filing it as a separate bug.
The following test program dies with GCC 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #3 from sgunderson at bigfoot dot com ---
Still there in GCC 7.2.1 (exact same assembler output), and in 8.0 snapshot
20171017.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
Reduced testcase (automatically; it might be possible to reduce further):
enum a { b };
struct c {
template < a >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81716
--- Comment #2 from sgunderson at bigfoot dot com ---
Still there in:
gcc version 8.0.0 20171017 (experimental) [trunk revision 253812] (Debian
20171017-1)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
Reduced test case below. Regression happens when compiling a part of MySQL
which uses Boost (1.65.0); original code was valid but reduced case is not.
(Reduction also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82780
--- Comment #1 from sgunderson at bigfoot dot com ---
Here's a version that's valid C++:
class a {
};
template class c { c(c &) : a(static_cast
(e.d)) {} a d; };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335
--- Comment #3 from sgunderson at bigfoot dot com ---
Appears to have been fixed in GCC 8, indeed.
#include
std::optional func()
{
return 3;
}
GCC 7 (-O2) compiles to:
0: 48 89 f8mov%rdi,%rax
3: c7 07 03
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Created attachment 44296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44296=edit
Test case
Hi,
We noticed that MySQL does not pass its test su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #12 from sgunderson at bigfoot dot com ---
The spurious warning seems to be gone in GCC 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
--- Comment #5 from sgunderson at bigfoot dot com ---
Ah, so it's allowed to send structs and classes, just not non-PODs. So that's
why the conversion to a pointer happens.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Test program:
#include
#include
int main(void)
{
std::string str;
printf("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
--- Comment #3 from sgunderson at bigfoot dot com ---
printf aside, is this thing actually supported in varargs? I thought non-PODs
were not allowed in varargs, period. (If it's not allowed, I'm not sure why the
compiler even tries.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #2 from sgunderson at bigfoot dot com ---
OK, starting a reduce that also checks for no -Wreturn-type warnings.
87 matches
Mail list logo
