: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acahalan at gmail dot com
Target Milestone: ---
__m64 __attribute__((noinline)) mmx(__m64 x, __m64 y){return _mm_add_pi8(x,y);}
That gives 6 lines of assembly. (movq,movdq2q,paddb,movq,movq,ret) Stuff even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557
--- Comment #5 from Albert Cahalan ---
This example shows the most simple form of the problem:
unsigned long long ull;
void simple64(void){
ull = 0;
}
NOTE: In the assembly below, I might have missing/excess parentheses. Assembler
synta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557
--- Comment #4 from Albert Cahalan ---
Mostly it's more like PR58741 because of the long long issue.
PR22141 (and PR23684 which is a better match) is about merging small things.
Two of the six examples here show that problem, those being the one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557
--- Comment #1 from Albert Cahalan ---
For the 32-bit i386, gcc 4.8.4 doesn't zero a pair of registers. I doubt gcc is
doing the best for -Os regarding addressing, but at least the i386 is getting
better code than the m68k coldfire.
Assignee: unassigned at gcc dot gnu.org
Reporter: acahalan at gmail dot com
Target Milestone: ---
Created attachment 38196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38196&action=edit
C source, gcc 5.3.0 assembly output, IDA Pro disassembly
This is C with gc
--- Comment #2 from acahalan at gmail dot com 2007-11-20 05:35 ---
(In reply to comment #1)
> Please read the dicussion starting at:
> http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html
Discussion noted.
It seems like the 100% workable solution is to let the C++ compiler
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
--- Comment #6 from acahalan at gmail dot com 2007-06-26 03:37 ---
(In reply to comment #5)
> This is related to or really a dup of bug 4417.
It's only related, not a dup, though bug 4417 is sort of a subset.
There appears to be no possible set of gcc options that will allow c
--- Comment #4 from acahalan at gmail dot com 2007-06-26 03:10 ---
(In reply to comment #3)
> Subject: Re: Missed optimizations with -fwhole-program -combine
>
> I would not expect this to be fixed anytime soon. I have yet to find
> any real people who use either combin
--- Comment #2 from acahalan at gmail dot com 2007-02-08 19:05 ---
(In reply to comment #1)
> Subject: Re: New: C99 initializer can't see anon struct/union
> members
>
> Looks like bug 10676 to me.
Perhaps, but that bug has an incorrect keyword. It is marked "
CONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30737
--- Comment #4 from acahalan at gmail dot com 2006-12-06 04:07 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The compiler is failing to follow the documented behavior.
> Because I (or anyone else) have not got around to actually testing the
> testcase
>
middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30026
--- Comment #6 from acahalan at gmail dot com 2006-11-29 05:11 ---
This hits it too. (example is PowerPC)
///
#include
char *foo(char *buf)
{
short temp;
int temp1;
*buf++=42;
temp = 0xfeed;
memcpy(buf, &temp, sizeof(temp));
buf+=sizeof(temp);
t
--- Comment #2 from acahalan at gmail dot com 2006-11-29 05:09 ---
This hits it too. (example is PowerPC)
///
#include
char *foo(char *buf)
{
short temp;
int temp1;
*buf++=42;
temp = 0xfeed;
memcpy(buf, &temp, sizeof(temp));
buf+=sizeof(temp);
t
--- Comment #17 from acahalan at gmail dot com 2006-11-24 00:11 ---
(In reply to comment #13)
> The question I asked is "why doesn't this happen for 'const'"? That
> turned out to be a good question, because it leads to the better
> question
--- Comment #5 from acahalan at gmail dot com 2006-11-24 00:02 ---
Created an attachment (id=12680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12680&action=view)
crash5.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #4 from acahalan at gmail dot com 2006-11-24 00:01 ---
Created an attachment (id=12679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12679&action=view)
crash4.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #3 from acahalan at gmail dot com 2006-11-24 00:01 ---
Created an attachment (id=12678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12678&action=view)
crash3.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #2 from acahalan at gmail dot com 2006-11-24 00:00 ---
Created an attachment (id=12677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12677&action=view)
crash2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #1 from acahalan at gmail dot com 2006-11-23 23:59 ---
Created an attachment (id=12676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12676&action=view)
crash1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #2 from acahalan at gmail dot com 2006-10-19 05:28 ---
Why is this still UNCONFIRMED, and why is it marked enhancement?
The compiler is failing to follow the documented behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
--- Comment #10 from acahalan at gmail dot com 2006-10-18 01:01 ---
An enum will crash it too. This one is in modified_type_die like the original.
$ gcc -g3 -Os -W -Wall -std=gnu99 kku.c
kku.c:3: internal compiler error: in modified_type_die, at dwarf2out.c:8463
Please submit a full
--- Comment #9 from acahalan at gmail dot com 2006-10-18 00:57 ---
I did it again, but this time in splice_child_die.
$ gcc -g3 -Os -W -Wall -std=gnu99 jji.c
jji.c:3: warning: useless storage class specifier in empty declaration
jji.c:5: internal compiler error: in splice_child_die, at
--- Comment #8 from acahalan at gmail dot com 2006-10-17 21:05 ---
In case comment #4 was meant to imply that a non-ICE error is fine:
Please note that the crashing code is very nearly the __may_alias__ example
given in the gcc documentation. The main difference is that I used a struct
--- Comment #2 from acahalan at gmail dot com 2006-10-12 01:25 ---
Hey, I don't even need to use the types. The typedef alone
is enough to ICE gcc:
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int main(int argc, char
--- Comment #1 from acahalan at gmail dot com 2006-10-12 01:20 ---
Other ways to ICE gcc:
///
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
S_t *handler(void *vp)
{
cmonkey *cm = vp;
return
lan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
--- Comment #11 from acahalan at gmail dot com 2006-10-01 07:50 ---
(In reply to comment #10)
> > I'm more familiar with the POSIX/UNIX standardization than the C/C++
> > standardization. Perhaps they have very different rules, but what
> > I've seen wi
--- Comment #9 from acahalan at gmail dot com 2006-10-01 05:32 ---
(In reply to comment #4)
> This is definitely firmly in the class of "extension to the language that
> requires a thorough proposal to be presented to the standards committee"
Of course. I mentioned
--- Comment #2 from acahalan at gmail dot com 2006-09-27 04:03 ---
(In reply to comment #1)
> Use autoconf like the GNU coding style recommends.
That is exactly the the main "gross hack" I refer to.
Hacks like autoconf should not be necessary. People
also hack around the
--- Comment #8 from acahalan at gmail dot com 2006-09-27 03:47 ---
(In reply to comment #5)
> Did you read the documention?
> Warning: if you use this switch, and num is nonzero, then you must build all
> modules with the same value, including any libraries. This includes t
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29247
--- Comment #4 from acahalan at gmail dot com 2006-09-27 02:19 ---
(In reply to comment #3)
> (In reply to comment #2)
> First you should not be using options that change the ABI if you don't know
> what you are doing. because they change the ABI. Second, none of options
--- Comment #5 from acahalan at gmail dot com 2006-09-27 02:07 ---
(In reply to comment #4)
> Except it is better just to fix your code for aliasing issues.
Yes, and all other bugs should be fixed as well.
This is often impractical. Is there even one large modern
kernel which
--- Comment #3 from acahalan at gmail dot com 2006-09-27 00:18 ---
[EMAIL PROTECTED] is correct, it's a missed-optimization bug.
(if this isn't a bug, then no missed optimization is a bug)
--
acahalan at gmail dot com changed:
What|Removed
--- Comment #2 from acahalan at gmail dot com 2006-09-27 00:15 ---
(In reply to comment #1)
> Yes those change the ABI which means don't use them unless you know what you
> are doing.
I damn well do know what I want to do, and gcc does not support it.
What, you expect me
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
convention
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242
e -Wstrict-aliasing=2 warning option.
--
Summary: -fno-strict-aliasing disables restrict
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned
--- Comment #37 from acahalan at gmail dot com 2006-09-26 15:33 ---
(In reply to comment #36)
> > Evidence: this bug has existed for ages, meanwhile aliasing violations keep
> > getting reported as compiler bugs.
> This bug (PR28778) has only existed for the last two
--- Comment #35 from acahalan at gmail dot com 2006-09-26 14:16 ---
(In reply to comment #34)
> Subject: Re: [4.0/4.1/4.2 Regression] alias
> bug with cast and call clobbered
>
> On Tue, 2006-09-26 at 04:44 +0000, acahalan at gmail dot com wrote:
> >
> &
--- Comment #33 from acahalan at gmail dot com 2006-09-26 04:44 ---
(In reply to comment #28)
> If you exclude strict type-based rules, the answer to "what can foo
> clobber" in the example is the same as asking "what can the first
> argument of foo acces
--- Comment #2 from acahalan at gmail dot com 2006-09-26 04:31 ---
(In reply to comment #1)
> A quick question here. Why not use a .s file instead?
REASON #1
Sometimes people want to use --combine -fwhole-program, but the documentation
for -fwhole-program starts with this:
&quo
--- Comment #3 from acahalan at gmail dot com 2006-09-26 04:06 ---
(In reply to comment #2)
> If you tried the page-of-functions idea, what would you do if you'd used all
> the functions on the page and needed another one?
>
You'd do the same as if you'd use
--- Comment #5 from acahalan at gmail dot com 2006-09-22 02:24 ---
(In reply to comment #4)
> I still don't see why my code should not compile even for register starved
> x86.
> Including the -fomit-frame-pointer optimization should allow using the ebp
> register
does not recognize memcpy and optimize it
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29174
dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29173
--- Comment #3 from acahalan at gmail dot com 2006-09-21 18:49 ---
foo 0 $ cat foo.c
void *memcpy(void *restrict, const void *restrict, unsigned long);
void *memcpy(void *restrict dst, const void *restrict src, unsigned long n)
{
const char *p = src;
char *q = dst
--- Comment #2 from acahalan at gmail dot com 2006-09-21 18:15 ---
A simple test case would involve the code I gave plus whatever it takes to make
gcc decide to call memcpy. What is the most simple thing which triggers that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
+;
}
#endif
return dst;
}
--
Summary: forgotten memcpy with -ffreestanding -fwhole-program --
combine
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
--- Comment #9 from acahalan at gmail dot com 2006-09-21 06:18 ---
Regarding comment #3, why is -fwhole-program accepted without -ffreestanding?
Unlike the original poster (who wrote "I don't care about this anymore."),
this is a rather annoying bug for me. I'll
le-program --
combine
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29159
--- Comment #4 from acahalan at gmail dot com 2006-09-21 05:12 ---
Target powerpc-*-* is wrong. See bug 29158 (my dupe) for the i386 assembly
produced by a slightly more recent compiler. It's x86_64 too.
It's not just (char*) either. It's (short*) and even struct member
nent: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29158
--- Comment #11 from acahalan at gmail dot com 2006-04-24 04:10 ---
When did gcc suddenly stop accepting new extensions?
For years gcc has been more of a practical real-world compiler than a pedantic
standards-only compiler. Many extensions have been added, both useful and
useless
--- Comment #9 from acahalan at gmail dot com 2006-04-23 20:39 ---
Regarding Comment #8:
Of course I do not want g++ to be a perfect superset of gcc. That is
unreasonable, because it would break legitimate standards-conforming C++ code.
I only ask that C compatibility be provided for
--- Comment #10 from acahalan at gmail dot com 2006-04-23 02:09 ---
A couple quotes from Linus on the linux-kernel mailing list, in response to the
idea (expressed in comment #3 above) of having the assembly set up the normal
stack:
-- 1 --
Sure, we could just do a slower system call
--- Comment #9 from acahalan at gmail dot com 2006-04-23 02:05 ---
Actually, there is no desire to prevent sibling calls. That's a hack. Sibling
calls are desirable as long as they don't muck with the incoming argument
stack.
Using -fno-sibcalling is definitely out of the qu
--- Comment #5 from acahalan at gmail dot com 2006-04-22 07:12 ---
No legal C++ code would break if g++ were less incompatible with C. Why be
incompatible?
There are cases where gcc takes far greater liberties with the standards,
breaking fully legal code. (trigraphs for example) The
--- Comment #3 from acahalan at gmail dot com 2006-04-22 01:03 ---
I saw it on Fedora Core 5, which I believe is gcc 4.1, and I saw it on a gcc
which describes itself as:
gcc version 4.0.3 (Debian 4.0.3-1)
So that is two rather different gcc versions. One is x86-64, the other is
32
--- Comment #4 from acahalan at gmail dot com 2006-04-21 03:41 ---
Mostly, sibcalling does not happen. So in the common case, setting up the
normal ABI-specified stack would be a waste.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
--- Comment #2 from acahalan at gmail dot com 2006-04-21 03:16 ---
#define asmlinkage __attribute__((regparm(0)))
#define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret))
As I recall, the kernel expects the stack to remain untouched
so that
iority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
--- Comment #24 from acahalan at gmail dot com 2006-04-21 02:11 ---
PIC register: while the user could save and restore this, the whole point of
this fancy assembly notation is so that gcc can do nice scheduling and register
allocation. The save and restore should thus be done by gcc
--- Comment #2 from acahalan at gmail dot com 2006-02-22 04:16 ---
Oops, it is indeed documented. Sorry. (recent change?)
Still, it would be lots better if warning options simply enabled the necessary
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26411
iasing does not enable analysis
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.g
--- Comment #6 from acahalan at gmail dot com 2006-02-22 03:28 ---
Yes, char pointers are special. I'd like a non-special char pointer.
I often know that a char pointer will never alias non-char data, but can not
prove that it obeys all the complicated rules for __restrict.
Fo
--- Comment #6 from acahalan at gmail dot com 2006-02-22 03:18 ---
I don't think it is legit to extract any sort of certainty from this:
if (x == 0)
abort();
return x;
There may be a SIGABRT handler which allows the program to live.
--
http://gcc.gnu.org/bug
--- Comment #5 from acahalan at gmail dot com 2006-02-22 03:14 ---
The code in comment #4 really isn't the same as the original. The original is a
decorated version of this:
if(x && y)
It is meant to express that:
x is likely
y is likely
x&&y is unlikely
Here,
--- Comment #4 from acahalan at gmail dot com 2006-02-20 04:11 ---
It's interesting that you say "__builtin_expect gives the same probability on
all targets". I'm not exactly sure what you mean, but I'll guess that you mean
it states that the condition will be
--- Comment #2 from acahalan at gmail dot com 2006-02-20 04:00 ---
VRP (value range propagation, if I guess right) doesn't always have the data it
needs. Commonly, people split projects into multiple files and do not use
-fwhole-program to compile the project. This seems to be the
--- Comment #2 from acahalan at gmail dot com 2006-02-20 03:49 ---
I gave two examples. (you may assume I want code to run fast)
I first saw this feature proposed on the linux-kernel mailing list when there
was some argument over whether or not __builtin_expect() should be used in a
--- Comment #4 from acahalan at gmail dot com 2006-02-20 03:29 ---
There have been times when I could not prove to myself that __restrict would be
safe (it may have been), yet I knew that the char pointer would not alias with
non-char pointers.
(sorry to not have a nice chunk of code
--- Comment #2 from acahalan at gmail dot com 2006-02-20 03:18 ---
For variables that are commonly used in a large project, you sure wouldn't want
to be putting conditional code all over the place if you could avoid it. The
choice could be something like:
a. put #if TARGET_WANTS_X
--- Comment #4 from acahalan at gmail dot com 2006-02-19 23:20 ---
Here is an example of something that is seriously awkward to do in C.
Suppose I want to ensure that several variables end up in the same cache line.
I'd like to do it this way:
struct {
short s1;
sho
--- Comment #3 from acahalan at gmail dot com 2006-02-19 23:09 ---
Here is an example of something that fundamentally can not be done in plain C.
Suppose I have a large project with a badly-named global variable. When I
compile with -Wshadow, I get lots of complaints. I'd li
--- Comment #2 from acahalan at gmail dot com 2006-02-19 23:02 ---
Given that we have anon unions, and given that unions can exist at top level
and function level, this is a very logical extension. It lifts an annoying and
arbitrary restriction.
>From the user's point of vi
--- Comment #2 from acahalan at gmail dot com 2006-02-19 21:48 ---
Nope, at least if the documentation at
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html is what you refer to.
It would be good to document how strong the expectation is for each
architecture. Apparently the
--- Comment #2 from acahalan at gmail dot com 2006-02-19 21:40 ---
No, __restrict is too strong. It also, last I heard, couldn't be applied to a
type.
(if restrict was right, then using it on an int would be redundant)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
us: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26371
t top level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bug
org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
nu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
--
Summary: __builtin_expect needs better documentation
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan
ed at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26363
90 matches
Mail list logo
