: 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
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
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=edit
C source, gcc 5.3.0 assembly output, IDA Pro disassembly
This is C with gcc 5.3.0 target
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 #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 factor
attributes
--- 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 combine or -fwhole
--- 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 compiling
: 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=30737
--- 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 diagnostic,
which is far
--- 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
:).
I still don't see
dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30026
--- Comment #2 from acahalan at gmail dot com 2006-11-29 05:09 ---
This hits it too. (example is PowerPC)
///
#include string.h
char *foo(char *buf)
{
short temp;
int temp1;
*buf++=42;
temp = 0xfeed;
memcpy(buf, temp, sizeof(temp));
buf+=sizeof(temp);
temp1
--- Comment #6 from acahalan at gmail dot com 2006-11-29 05:11 ---
This hits it too. (example is PowerPC)
///
#include string.h
char *foo(char *buf)
{
short temp;
int temp1;
*buf++=42;
temp = 0xfeed;
memcpy(buf, temp, sizeof(temp));
buf+=sizeof(temp);
temp1
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 #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=12676action=view)
crash1.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=12677action=view)
crash2.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=12678action=view)
crash3.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=12679action=view)
crash4.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- 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=12680action=view)
crash5.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- 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 of what debugging output did you expect
--- 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 #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 #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
--- 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
at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
--- 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
--- 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 *argv
--- 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 with the one group is that the committee
--- 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 that.
I'm more familiar
--- 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 major releases which
--- 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 +, acahalan at gmail dot com wrote:
Although it wouldn't work
disables restrict
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
: 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
: gcc
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
--- 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 to edit
--- 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 |Added
--- 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 #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 you
gave
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 #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 the system
--- 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 problem
--- 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 used up all the stack space
--- 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:
Assume
--- 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 access in foo and its callees. Because
--- 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 check again tomorrow
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
: 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
--- 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
--- 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
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29173
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
--- 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 at least for leaf
: store merge optimization not done
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
--- 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 members.
--
http
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 #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
--- 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 #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
--- 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 question
--- 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 #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 #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
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 #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 it can restore that portion
dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
--- 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
--- 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
xy is unlikely
Here, the probability of x times
--- 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/bugzilla
--- 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.
For non
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.gnu.org/bugzilla
--- 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
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26363
: __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 at gmail dot com
http
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
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/bugzilla
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
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
--- 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
--- 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
--- 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 view
--- 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 like
--- 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;
short s2
--- 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_XXX
--- 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: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
--- 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 norm
--- 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 true X% of the time.
If so
90 matches
Mail list logo
