http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53724
Bug #: 53724
Summary: ICE when using the 'd' asm operand modifier
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53649
--- Comment #2 from Steven Fuerst svfuerst at gmail dot com 2012-06-13
15:40:19 UTC ---
I'm using the version of 4.7 packaged in Debian unstable. It apparently
contains everything up until June 12 in the 4.7 branch, plus a few other
patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53649
--- Comment #3 from Steven Fuerst svfuerst at gmail dot com 2012-06-13
15:46:13 UTC ---
Oops sorry. The source package is 4.7.0-13, but I'm still actually using the
binaries from 4.7.0-11, which was released before May 30.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53649
Bug #: 53649
Summary: ICE when using 'C' x86 asm constraint
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53353
Bug #: 53353
Summary: Missing error/warning when using __int128_t with
incorrect asm register constraints
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53354
Bug #: 53354
Summary: %z# asm specifier could be extended to support
immediate constraints
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53355
Bug #: 53355
Summary: Autovectorization of a simple loop could be improved.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53353
--- Comment #2 from Steven Fuerst svfuerst at gmail dot com 2012-05-15
01:54:46 UTC ---
Obviously a __int128_t fits in two registers. The bug is that gcc doesn't
warn/error about code mistakenly trying to fit it into one. Instead, gcc
generates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53353
--- Comment #4 from Steven Fuerst svfuerst at gmail dot com 2012-05-15
02:09:05 UTC ---
Actually, it is the rax:rdx pair that is most likely. ax:dx only has 32 bits.
rax:rdx is specified by the 'A' constraint, the only gpr option that is 128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
--- Comment #4 from Steven Fuerst svfuerst at gmail dot com 2012-02-02
06:11:27 UTC ---
Two more cases for simple boolean logic optimizations.
gcc-4.7 produces with -O3 for
int test_and(long long x, long long y)
{
return x y;
}
test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50339
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51954
Bug #: 51954
Summary: __int128_t negation can be optimized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51837
Bug #: 51837
Summary: Use of result from 64*64-128 bit multiply via
__uint128_t not optimized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51838
Bug #: 51838
Summary: Inefficient add of 128 bit quantity represented as 64
bit tuple to 128 bit integer.
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51839
Bug #: 51839
Summary: GCC not generating adc instruction for canonical
multi-precision add sequence
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50984
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35561
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48634
Summary: Missed optimization for use of __builtin_ctzll() and
__builtin_clzll
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949
--- Comment #3 from Steven Fuerst svfuerst at gmail dot com 2011-03-02
21:51:12 UTC ---
Having a quick look at generated code... it appears that this pattern doesn't
come up all that often. However, there is one case where it does: the epilogue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949
Summary: Missed optimization for -Os using xchg instead of mov.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47809
Summary: ICE in gimplify_expr, at gimplify.c:7291 [4.6]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309
Steven Fuerst svfuerst at gmail dot com changed:
What|Removed |Added
CC||svfuerst
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
about?)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC
.)
--
Summary: va_list usage missed optimization.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44053
--- Comment #1 from svfuerst at gmail dot com 2010-05-10 06:36 ---
A common technique is to benchmark a function by calling it many times i.e.
void foo(void)
{
/* foo's implementation */
}
int main(void)
{
int i;
for (i = 0; i LARGE_NUM; i++) foo();
return 0
--- Comment #5 from svfuerst at gmail dot com 2010-05-10 14:53 ---
The problem is that the list of these workarounds tends to increase with each
release of gcc. (i.e. noclone was added in gcc 4.5) It would be nice if there
was a single attribute to use that would work with all future
--- Comment #7 from svfuerst at gmail dot com 2010-05-10 22:44 ---
Perhaps an example usage helps:
The __float128 version of isnan() is rather slow. Trying different
implmentations to see which is faster required some benchmarking. However,
implementing the benchmark code requires
--- Comment #9 from svfuerst at gmail dot com 2010-05-10 23:27 ---
Remember that isnan() is a weird type-dependent macro. The special case I was
testing is the __float128 version. __float128's are passed in sse registers,
so using sse instructions to manipulate them can be a win
--- Comment #3 from svfuerst at gmail dot com 2010-04-30 16:12 ---
Oops, you are right. The 128 bit version needs an extra sbb on the end with
that code. (For some reason I was missreading the shr as a sar.):
mov%rsi,%rdx
shr$0x3f,%rdx
lea(%rdi,%rdx,1),%rax
and$0x1
--- Comment #4 from svfuerst at gmail dot com 2010-04-30 16:33 ---
Argh, the sar trick doesn't work when the number is negative and even. Sorry
about the extra noise.
This leaves as the best code:
mov%rsi,%rdx
shr$0x3f,%rdx
lea(%rdi,%rdx,1),%rax
and$0x1,%eax
sub
--- Comment #6 from svfuerst at gmail dot com 2010-04-30 20:30 ---
For posterity, I might as well note that with the sbb added on the end we don't
need the initial mov instruction if we do some register renaming. This leaves
the, hopefully optimal this time, five-instruction fragment
of constant __int128_t modulus
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build
: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43638
: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
--- Comment #2 from svfuerst at gmail dot com 2010-04-04 16:51 ---
Paragraph 2 in G.5.1 defines multiplication of a real floating point type by an
imaginary floating point type to be an imaginary type, not a complex type.
In addition, the Rationale for Annex G states that
It allow
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
44 matches
Mail list logo
