c++-specific)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw
--- Comment #1 from zackw at panix dot com 2006-07-12 22:33 ---
Created an attachment (id=11874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11874&action=view)
assembly output (bad on top, hand-corrected below)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #3 from zackw at panix dot com 2006-07-12 22:42 ---
I should mention that the exact command line flags were -O2
-fomit-frame-pointer -march=pentium4, and that I hand-tweaked the label numbers
for ease of reading.
Also, -fno-tree-ch does suppress this bad optimization, but
--- Comment #4 from zackw at panix dot com 2006-07-12 22:48 ---
I remembered that I had a build of 4.2 from last week lying around. It
generates even worse code - still with the duplication of most of the loop,
plus a bunch of unnecessary register fiddling and bad addressing mode
--- Comment #7 from zackw at panix dot com 2006-07-12 23:19 ---
Created an attachment (id=11875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11875&action=view)
C test case (with interesting implications)
I've found a plain C test case. In the process, I've f
--- Comment #8 from zackw at panix dot com 2006-07-12 23:21 ---
Zdenek: I don't see how you can say that what we get is optimal code "unless
optimizing for size". The code generated *will* be slower than the
alternative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #10 from zackw at panix dot com 2006-07-12 23:33 ---
I-cache. Also, more iterations before the branch predictors figure out what's
going on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #12 from zackw at panix dot com 2006-07-13 03:09 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > I-cache.
> this only matters if this increase in code size will make the code go
> out of instruction
--- Comment #14 from zackw at panix dot com 2006-07-13 03:40 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
It's a validation routine, yes, which is run over every pathname the
program is working on, and there can be hun
--- Comment #17 from zackw at panix dot com 2006-07-13 04:23 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> One more comment, a loop with an early exit is whole issue and that is the
> reason why all of the code in th
--- Comment #20 from zackw at panix dot com 2006-07-13 08:25 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > However, ch isn't just copying the loop header; it is also
> > copying the *entire body of the loo
--- Comment #21 from zackw at panix dot com 2006-07-13 08:28 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> on your real program, how much performance do you gain by hand-rewriting
> the assembler to look the way yo
for and all STL containers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com
http
--- Comment #6 from zackw at panix dot com 2007-04-15 21:22 ---
Bugs where the compiler proper crashes when run under the driver, but not when
run directly, can often be reproduced by varying the amount of space taken up
by environment variables, e.g.
x=
while :; do
x="x$x&qu
--- Comment #6 from zackw at panix dot com 2007-04-21 02:56 ---
I am inclined to think that this is an operating system bug and should be
worked around in the mingw32 libraries, not in cpplib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
--- Comment #5 from zackw at panix dot com 2007-09-06 17:35 ---
Nah, probably no one will ever get round to it and it's not that important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
value known to be positive
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw a
--- Comment #2 from zackw at panix dot com 2008-09-19 21:28 ---
I'd be fine with it being like uninitialized value warnings. The false
positives here are *really* annoying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
--- Comment #5 from zackw at panix dot com 2008-09-22 15:46 ---
I'm not monitoring consensus of developers anymore, but I think we *should*
either move these warnings to the middle end or do some CCP/VRP in the front
ends. The -Wuninitialized warnings are a lot less trouble tha
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
GCC 4.7 and 4.8 mis-optimize this test case:
int main(void)
{
char pstring[] = " hello world";
pstring[0] = (char) (__builtin_strlen(pstring) - 1);
__buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57230
--- Comment #5 from Zack Weinberg ---
It might be good to include stores to nonzero offsets in the test case, and
stores to bytes that used to be internal NULs, something like
int main(void)
{
char s[] = "abc\0def";
s[1] = (ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57230
--- Comment #8 from Zack Weinberg ---
(In reply to Jakub Jelinek from comment #6)
> We have just one strlen pass instance, and even if we optimize the first
> strlen
> there, having strlen pass duplicate constant propagation functionality just
> t
unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47623
Summary: false *negative* uninitialized warning
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723
--- Comment #1 from Zack Weinberg 2011-02-13 23:27:10
UTC ---
> I have run the build a second time and it makes it past the point
> where it segfaulted,
This means your problem is almost certainly *not* a bug in GCC, but rather a
hardware fault
mal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
I'm seeing a significant performance regression from 4.7 to 4.8 (targeting
x86-64) on the "salsa20" core function (this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315
--- Comment #2 from Zack Weinberg ---
Created attachment 30210
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30210&action=edit
self-contained test case
Here's a self-contained test case.
$ gcc-4.7 -std=c99 -O2 -march=native salsa20-regr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436
Bug #: 50436
Summary: Crash or hang on invalid template code
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436
--- Comment #1 from Zack Weinberg 2011-09-16 19:13:13
UTC ---
Here's a variant that hangs.
template struct VI {};
template
struct IP
{
static const bool r = IP::r;
};
template
struct V
{
static const bool r = IP::r;
VI vi;
};
struct X;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442
Bug #: 50442
Summary: Constructing T from implicit conversion to T&
ambiguous in C++0x mode, not C++98
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595
Bug #: 50595
Summary: template overload resolution insufficiently sensitive
to name dependency?
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCON
--- Comment #3 from zackw at panix dot com 2007-05-10 08:36 ---
What the heck are we doing calling access() in the first place? We should just
go ahead and try to execute .../cc1.exe for all relevant paths.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
--- Comment #3 from zackw at panix dot com 2007-05-12 07:34 ---
I believe Mike means to suggest you use -Wl,yada,yada,yada instead of -Xlinker
yada -Xlinker yada -Xlinker yada. (I also suspect this will help.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #4 from zackw at panix dot com 2007-06-06 00:41 ---
Subject: Re: Duplicate work, missed optimizations for registration of static
destructors
It's better, but build_cleanup is still being called twice in the
non-__cxa_atexit case, and I can't tell whether th
--- Comment #9 from zackw at panix dot com 2007-07-06 17:59 ---
Ian Taylor and I found a simpler patch that does not use langhooks, and also
has the virtue of working. ;-) Committed as rev 126424.
--
zackw at panix dot com changed:
What|Removed
ReportedBy: zackw at panix dot com
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32659
--- Comment #1 from zackw at panix dot com 2007-07-06 22:12 ---
Created an attachment (id=13858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13858&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32659
--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 ---
*** This bug has been marked as a duplicate of 32656 ***
--
zackw at panix dot com changed:
What|Removed |Added
--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 ---
*** Bug 32659 has been marked as a duplicate of this bug. ***
--
zackw at panix dot com changed:
What|Removed |Added
--- Comment #3 from zackw at panix dot com 2007-07-07 00:06 ---
Created an attachment (id=13859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13859&action=view)
Minimized test case
Here's a minimal test case (from my duplicate report of this, #32659). I
analyzed it
--- Comment #4 from zackw at panix dot com 2007-07-07 00:07 ---
Adding DJ to cc: list, confirming.
--
zackw at panix dot com changed:
What|Removed |Added
--- Comment #5 from zackw at panix dot com 2007-07-07 00:15 ---
Created an attachment (id=13860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13860&action=view)
Even smaller test case
--
zackw at panix dot com changed:
What|Removed
--- Comment #6 from zackw at panix dot com 2007-07-07 00:20 ---
Created an attachment (id=13861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13861&action=view)
and smaller still
I can't believe I didn't think of these reductions three hours ago...
--
zackw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Zack Weinberg changed:
What|Removed |Added
CC||zackw at panix dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Zack Weinberg changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
--- Comment #9 from Zack Weinberg ---
... whoops, hit send a little too early. AFAICT, the relevant code is
call_may_clobber_ref_p_1 in tree-ssa-alias.c; I would say that the uses of
flag_errno_math under the cases BUILT_IN_MALLOC, ALIGNED_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
--- Comment #14 from Zack Weinberg ---
I don't see why it would _ever_ make sense for -fno-alloc-errno to default to
the setting of -fno-math-errno. The math functions and the memory allocation
functions are independent components of the C libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885
Zack Weinberg changed:
What|Removed |Added
CC||zackw at panix dot com
--- Comment #14
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
On any ABI where arguments to a variadic function are passed in the same places
that they would be if they were arguments to a non
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
This snippet
```
extern void thefun_called_with_nonnull_arg (void)
__attribute__((__warning__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #2 from Zack Weinberg ---
Additional fun detail:
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #4 from Zack Weinberg ---
(In reply to Richard Biener from comment #3)
> I guess you want to use
>
> __builtin_constant_p (b != 0)
>
> instead.
That wouldn't do what I want. The goal is to warn for any argument _other
than_ a comp
||2019-06-12
CC||zackw at panix dot com
Ever confirmed|0 |1
--- Comment #1 from Zack Weinberg ---
Confirming. This has now bitten an attempt to use __has_include in glibc, see
discussion starting at
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #13 from Zack Weinberg ---
Since examples of this error were observed with base 10, I think the warning
should cover 10^i for decimal literal i, too.
Relatedly, “note: ^ performs exclusive or, not exponentiation” might be a nice
addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Zack Weinberg changed:
What|Removed |Added
CC||zackw at panix dot com
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #30 from Zack Weinberg ---
It's been a very long time and I don't know exactly what changed, but GCC 7.3
generates essentially the same code for both of the functions in the "C test
case" and I would not describe that code as "bad".
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
This function
int has_bad_chars(unsigned char *str, __SIZE_TYPE__ len)
{
for (unsigned char *c = str; c <
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
The following test case is a mechanical reduction from the implementation of
vfpri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772
--- Comment #2 from Zack Weinberg ---
You don't appear to have the exact same build as me. But there's something
fishy going on with that, because as far as I can tell, SVN rev 258338 is a
*trunk* revision, not a gcc-7-branch revision.
Anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772
--- Comment #3 from Zack Weinberg ---
Created attachment 43607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43607&action=edit
-fdump-tree-stdarg output for test case from problem compiler
I do not entirely understand how to read this (wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772
--- Comment #4 from Zack Weinberg ---
The last actual _change_ in my GCC build is
r258315 | denisc | 2018-03-07 04:13:12 -0500 (Wed, 07 Mar 2018) | 9 lines
Backport from mainline
2018-02-07 Georg-Johann Lay
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772
--- Comment #7 from Zack Weinberg ---
I no longer remember enough about GIMPLE to comment on your actual proposed
fix, but I do have a small nitpick on the test case:
+va_arg (ap, long double); /* { dg-bogus "may be used
uni
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
Bug #: 56166
Summary: std::string::clear() can allocate memory despite being
marked noexcept
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #1 from Zack Weinberg 2013-01-31 18:21:49
UTC ---
Created attachment 29320
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29320
test case
In case you're wondering, this was an attempt to do at least *some* testing of
a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #4 from Zack Weinberg 2013-02-01 00:48:43
UTC ---
Is vstring going to be promoted to std::string in the *near* future? it doesn't
seem done to me, eg there is no stringstream for it, and it appears to generate
bulkier code. (no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #18 from Zack Weinberg 2013-02-02 21:59:37
UTC ---
I find it a little disappointing that what should have been a straightforward
additional optimization has gotten totally derailed into bikeshedding of an
enormous class of buil
-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
Consider
#include
#include
#include
using std::string;
inline unsigned char hexval(unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178
--- Comment #2 from Zack Weinberg ---
That was my working hypothesis as well. Isn't there some way we can annotate
s->data to reassure the compiler that *this* char* doesn't alias? I don't know
enough about the guts of std::string to know wheth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178
--- Comment #5 from Zack Weinberg ---
It seems to me that a pair of extended integer types (signed and unsigned),
that are the same size as `char` but don't get the special TBAA treatment for
"character types", would be easier to implement and va
ty: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
Consider
#define warn1(msg) _Pragma (#msg)
#define warn(msg) warn1 (GCC warning msg)
#define lengthy_explan
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
If a function that returns an empty struct is tagged with attribute
warn_unused_result, any call will trigger the warning, even if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82134
--- Comment #2 from Zack Weinberg ---
The claim in the Stack Overflow post was that this was useful in a scenario
involving machine-generated code that couldn't return void for some external
reason, but they didn't go into any kind of detail.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82752
Zack Weinberg changed:
What|Removed |Added
CC||zackw at panix dot com
--- Comment #1
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
On Linux/glibc,
$ cat > test.c <
ino_t inode;
EOF
$ gcc -std=c89 -fsyntax-only test.c
test.c:2:1: error: unk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83236
--- Comment #3 from Zack Weinberg ---
Maybe name_reserved_for_implementation_p should be a langhook?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83236
--- Comment #5 from Zack Weinberg ---
I was just thinking that other language front-ends might want to offer
spell-checking suggestions with their own rules for which names are/aren't
appropriate to suggest in context, but maybe we can worry abou
--- Comment #4 from zackw at panix dot com 2010-04-08 17:28 ---
(In reply to comment #0)
> When this testcase, using inline assembly, is compiled with -Os, -O2, or -O3
> it segfaults. -O0 and -O1 allow it to run correctly.
>
> Moving the inline assembly into a separ
--
zackw at panix dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
99+% of the time, when the compiler proper dies on signal 9, it's because we're
NCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
(From https://stackoverflow.com/questions/33614455/ :)
The C++ comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265
--- Comment #2 from Zack Weinberg ---
This problem apparently goes back at least as far as 4.8. Stack Overflow
people found a number of variations, please consult
https://stackoverflow.com/questions/23033043/is-it-a-new-c11-style-of-comments
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #34 from Zack Weinberg ---
> As I tried to explain, it is currently design decision to have one declaration
> and one symtam node for one symbol. The one decl rule was introduced by
> Codesourcery (Zack) in 2003-4. He updated fronten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249
--- Comment #4 from Zack Weinberg ---
The "delta-minimized self-contained test case" should require only `-O2 -flto`
to reproduce the problem. The other test case, however, should require
`-D_FORTIFY_SOURCE=2` in addition, and to be compiled aga
diagnostic
Severity: enhancement
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
The warning for a // comment continued on the next line by a backslash is
"warning: multi-line comment&
: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
This program
#include
#include
int
main(void)
{
size_t n = 1000;
float *x = calloc(n,sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
--- Comment #2 from Zack Weinberg ---
I observe that the `memcpy` does get lowered to inline code. Is it just a
phase-ordering problem that we then don't detect the stores as dead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595
Zack Weinberg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Created attachment 33388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33388&action=edit
test case (compile on recent glibc system)
Compile the attached program on a recent-glibc syst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249
--- Comment #1 from Zack Weinberg ---
Created attachment 33389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33389&action=edit
Delta-minimized self-contained test case
Requires no headers anymore.
Delta-minimization revealed something in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249
--- Comment #2 from Zack Weinberg ---
Incidentally, yes, the test case is based on a real program.
erity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307
--- Comment #2 from Zack Weinberg ---
(In reply to Marc Glisse from comment #1)
> -fsanitize=null seems to imply -fno-delete-null-pointer-checks, so I assume
> this is on purpose. It would actually be quite natural for the sanitizer to
> insert a
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Consider
#include
__m128i foo(char C)
{
return _mm_set_epi8( 0,C, 2*C, 3*C,
4*C, 5*C, 6*C, 7*C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Summary: missed optimization: integer overflow checks
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #2 from Zack Weinberg 2011-04-12 20:40:41
UTC ---
(In reply to comment #1)
>
> Two signed integers given that they are known to be positive, anyway.
> This may return unexpected results if either or both arguments are
> negative o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #4 from Zack Weinberg 2011-04-12 21:03:01
UTC ---
On Tue, Apr 12, 2011 at 1:52 PM, joseph at codesourcery dot com
wrote:
>> In the code that this is cut down from, both arguments are known to be
>> strictly
>> positive, but neither
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #5 from Zack Weinberg 2011-04-12 21:04:34
UTC ---
Addendum: what would *you* describe as the correct C idiom for
ensuring that the product of two signed integers was positive and did
not overflow the range of a same-sized signed integ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45861
Summary: Possible missed optimization - array ops vs
shift-and-mask
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
--- Comment #2 from zackw at panix dot com 2010-05-17 23:59 ---
So it has to be a little smarter than the obvious, so what else is new.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
1 - 100 of 119 matches
Mail list logo
