[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793 --- Comment #3 from thutt at vmware dot com --- Thanks for the quick triage. If the optimizer is getting confused about control / data flow, is it possible that it's making bad decisions for codegen?
[Bug c/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793 --- Comment #1 from thutt at vmware dot com --- Also using godbolt.org, this sample fails from 4.9.0 to trunk.
[Bug c/101793] New: Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Bug ID: 101793
Summary: Incorrect production of ‘may be used uninitialized in
this function [-Werror=maybe-uninitialized]'
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
Target Milestone: ---
/*
When compiled with the following options using the C compiler:
-Werror \
-Wmaybe-uninitialized\
-O1 \
-fno-diagnostics-show-caret \
this code produces the following diagnostic
./rk.c: In function ‘f’:
./rk.c:26:16: error: ‘saved’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
This warning is erroneously produced, since 'state' is saved and
restored under the same condition ('cond').
*/
unsigned fn(void);
extern unsigned state;
unsigned
f(unsigned p)
{
unsigned saved;
unsigned v0 = fn();
unsigned cond = p != 0;
if (cond) {
saved = state;
if (v0 != 0) {
p = 0;
}
}
if (v0 > 0) {
return 0;
}
if (fn()) {
if (cond) {
state = saved;
}
return p;
}
return 0;
}
[Bug c/98132] New: ‘target_mem_ref’ not supported by expression internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132
Bug ID: 98132
Summary: ‘target_mem_ref’ not supported by expression internal
error
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
Target Milestone: ---
#if 0
The program below, compiled with:
x86_64-vmk-linux-gnu-gcc (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
fails with the following internal gcc error and an incorrect warning:
#‘target_mem_ref’ not supported by expression#’./main.c: In function ‘main’:
./main.c:15:12: warning: is used uninitialized in this function
[-Wuninitialized]
return (*(uint16*)[i] >> i) & 0x1ff;
^~~
./main.c:19:1: note: ‘ote’ was declared here
f1(t0_t ote)
^~
The compiler used was built in-house.
The command line is:
CC=
${CC} \
-nostdinc \
-O2 \
-Wuninitialized \
-o ./main.o \
-c ./main.c
#endif
typedef unsigned char uint8;
typedef unsigned short int uint16;
typedef struct t0_t {
uint8 field[5];
} t0_t;
extern t0_t ote;
static unsigned
f0(t0_t ote, unsigned i)
{
return (*(uint16*)[i] >> i) & 0x1ff;
}
static unsigned
f1(t0_t ote)
{
int i;
for (i = 0; i < 4; i++) {
unsigned j = f0(ote, i);
if (j == 1) {
return 1;
}
}
return 0;
}
int
main(int argc, char **argv)
{
return f1(ote);
}
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 thutt at vmware dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from thutt at vmware dot com --- (In reply to Andrew Pinski from comment #6) (In reply to thutt from comment #5) Is there simple explanation for the difference in behavior? Is the preprocessed source the same? I bet glibc enables some inline function at -O1. Yes, the cpp output is different. Because this produces different results for -O0 and -O1, I'm reopening because the compiler really shouldn't fail with one setting and succeed with another.
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #9 from thutt at vmware dot com ---
(In reply to Andrew Pinski from comment #8)
Since glibc controls the headers we (GCC) project cannot do anything.
???
From your standpoint of having cpp produce different output, I understand
your position that the gcc project cannot do anything.
If you look from the standpoint of the user of gcc, that position makes
little sense: changing the value of a compiler option should not cause
code to suddenly produce an error.
The problem doesn't lie in the header file, though it could be fixed there
with preprocessor work.
The problem really lies in the fact that the compiler is producing
an error message for a function that has been parsed, but has not been used:
extern __inline __attribute__ ((__gnu_inline__)) double
__NTH (wcstod (__const wchar_t *__restrict __nptr,
wchar_t **__restrict __endptr))
{ return __wcstod_internal (__nptr, __endptr, 0); }
From the standpoint of the user, that particular issue
*is* addressable by the gcc team.
Course, that's from the standpoint of the user...
Why are you using -mno-sse on an user space application anyways?
I volunteer to file defects against gcc because I have an open account,
but I can't speak to the reasoning behind each one that is provided to
me -- I just validate the information, and try to write up a good synopsis.
In this particular case, I think it was found during preliminary testing
before upgrading the compiler; it may have been a one-off by-hand program
to do some other testing, I don't really know... I can go back and ask if you
are really curious...
For the team that I work on, we don't want hardware-using FPU code generated,
mostly.
That was the genesis of the other sse-related ticket I recently filed.
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #5 from thutt at vmware dot com --- (In reply to Andrew Pinski from comment #3) (In reply to thutt from comment #2) Can you please explain why it's invalid to return a double if SSE is disabled? SSE is an x86-specific hardware implementation and has nothing to do with language validity from my standpoint. On x86_64 the ABI says doubles are returned (and passed) via the SSE registers. Compiling the same program with gcc-4.8 -m64 -mno-sse -c -o /tmp/gungla.o /tmp/gungla.c does not exhibit the issue. Is there simple explanation for the difference in behavior?
[Bug c/57356] New: gcc-4.8: SSE2 instructions generated with '-mno-sse2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57356
Bug ID: 57356
Summary: gcc-4.8: SSE2 instructions generated with '-mno-sse2'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse2' command line option: SSE2 instructions are still
generated.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse2 -c -o /tmp/gungla.o /tmp/gungla.c
Sample Code:
typedef struct s128 {
char x[16];
} s128;
typedef struct wrapper {
s128 elem;
} wrapper;
void test2(s128 *);
void
test(wrapper **p, int *num)
{
int i;
s128 *a = (*p)-elem;
s128 b = *a;
for (i = 1; i *num; i++) {
test2(a);
if (i == 10) {
*a = b;
break;
}
}
if (p) {
*p = 0;
}
}
We have not been able to simplify this code any further.
Disassembly of section .text:
test:
0:41 56push %r14
2:41 55push %r13
4:41 54push %r12
6:55 push %rbp
7:53 push %rbx
8:48 83 ec 10 sub$0x10,%rsp
c:49 89 fe mov%rdi,%r14
f:48 89 f5 mov%rsi,%rbp
12:4c 8b 2f mov(%rdi),%r13
-- 15:f3 41 0f 6f 45 00movdqu 0x0(%r13),%xmm0
-- 1b:66 0f 7f 04 24 movdqa %xmm0,(%rsp)
20:83 3e 01 cmpl $0x1,(%rsi)
23:7f 32jg 57 test+0x57
25:eb 22jmp49 test+0x49
27:4c 89 e7 mov%r12,%rdi
2a:e8 00 00 00 00 callq 2f test+0x2f
2b: R_X86_64_PC32test2-0x4
2f:83 fb 0a cmp$0xa,%ebx
32:75 0djne41 test+0x41
34:66 0f 6f 0c 24 movdqa (%rsp),%xmm1
39:f3 41 0f 7f 4d 00movdqu %xmm1,0x0(%r13)
3f:eb 08jmp49 test+0x49
41:83 c3 01 add$0x1,%ebx
44:39 5d 00 cmp%ebx,0x0(%rbp)
47:7f dejg 27 test+0x27
49:4d 85 f6 test %r14,%r14
4c:74 1bje 69 test+0x69
4e:49 c7 06 00 00 00 00 movq $0x0,(%r14)
55:eb 12jmp69 test+0x69
57:4d 89 ec mov%r13,%r12
5a:4c 89 ef mov%r13,%rdi
5d:e8 00 00 00 00 callq 62 test+0x62
5e: R_X86_64_PC32test2-0x4
62:bb 01 00 00 00 mov$0x1,%ebx
67:eb d8jmp41 test+0x41
69:48 83 c4 10 add$0x10,%rsp
6d:5b pop%rbx
6e:5d pop%rbp
6f:41 5cpop%r12
71:41 5dpop%r13
73:41 5epop%r14
75:c3 retq
One oddity is that using '-mno-sse', the offending instructions are
not generated. (Maybe this implies that the instructions are simply
misclassified as SSE, rather than SSE2?)
gcc-4.7 does not exhibit the problem with the same code.
Can you folks please confirm, or refute, if gcc-4.7 suffers from the
same defect?
Possibly related to bug 46716.
[Bug c/57357] New: Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
Bug ID: 57357
Summary: Error with '-mno-sse' and include wchar.h
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse' command line option: an error is reported when including
wchar.h.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse -c -o /tmp/gungla.o /tmp/gungla.c
Sample Code:
#include wchar.h
Sample Output:
In file included from /tmp/gungla.c:1:0:
/opt/gcc-4.8.0/lib/gcc/x86_64-linux5.0/4.8.0/include-fixed/wchar.h: In
function 'wcstod':
/opt/gcc-4.8.0/lib/gcc/x86_64-linux5.0/4.8.0/include-fixed/wchar.h:563:1:
error: SSE register return with SSE disabled
{ return __wcstod_internal (__nptr, __endptr, 0); }
^
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #2 from thutt at vmware dot com --- Can you please explain why it's invalid to return a double if SSE is disabled? SSE is an x86-specific hardware implementation and has nothing to do with language validity from my standpoint.
[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264 --- Comment #7 from thutt at vmware dot com --- (In reply to Uroš Bizjak from comment #6) (In reply to thutt from comment #5) Does the same error exist in the 4.8 branch, or any other forward moving branch? No, 4.8 and newer branches already contain the original patch. Sorry to be a bother, but can you tell me if the issue was / is in the 4.4 branch?
[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264 --- Comment #9 from thutt at vmware dot com --- (In reply to Uroš Bizjak from comment #8) (In reply to thutt from comment #7) (In reply to Uroš Bizjak from comment #6) (In reply to thutt from comment #5) Does the same error exist in the 4.8 branch, or any other forward moving branch? No, 4.8 and newer branches already contain the original patch. Sorry to be a bother, but can you tell me if the issue was / is in the 4.4 branch? Yes, cld was removed in 4.3.0. Please see PR36079 that introduced -mcld. When the sample test program provided above was compiled with gcc 4.4, it did not generate the stos instruction. However, each of 4.5, 4.6 and 4.7 did generate the stos instruction. Given this, I'd like to clarify your answer. If I may summarize: 4.3.0 stopped using cld. After cld was not used, an error existed in versions 4.4, 4.5, 4.6 and 4.7. The error was fixed in 4.8. You have backported the fix from 4.8 to 4.7. You did not backport to 4.5 and 4.6 because they are closed. You do not state, but I infer that 4.4 is also closed. Do you have an idea why the test case does not demonstrate the error on 4.4? Is there a test case that will demonstrate the error on 4.4? Thanks for your help and patience
[Bug c/57264] New: cld not emitted when string instructions used, and '-mcld' on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264
Bug ID: 57264
Summary: cld not emitted when string instructions used, and
'-mcld' on command line
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
A defect has been found in several versions of gcc with respect to the
'-mcld' option.
-mcld
This option instructs GCC to emit a cld instruction in the
prologue of functions that use string instructions. String
instructions depend on the DF flag to select between
autoincrement or autodecrement mode. While the ABI specifies the
DF flag to be cleared on function entry, some operating systems
violate this specification by not clearing the DF flag in their
exception dispatchers. The exception handler can be invoked with
the DF flag set which leads to wrong direction mode, when string
instructions are used. This option can be enabled by default on
32-bit x86 targets by configuring GCC with the --enable-cld
configure option. Generation of cld instructions can be
suppressed with the -mno-cld compiler option in this case.
Consider the following distillation of the issue (cld.c):
void test(int x, int **pp)
{
while (x) {
int *ip = *pp;
int *op = *pp;
while (*ip) {
int v = *ip++;
*op++ = v + 1;
}
}
}
To demonstrate the issue:
gcc -c -mcld -O1 -m64 -o cld.o cld.c
objdump --disassemble --reloc cld.o
An example failure case:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test:
0: 85 ff test %edi,%edi
2: 74 15 je 19 test+0x19
4: 48 8b 3e mov(%rsi),%rdi
7: 8b 07 mov(%rdi),%eax
9: 85 c0 test %eax,%eax
b: 74 f7 je 4 test+0x4
d: 83 c0 01 add$0x1,%eax
10: ab stos %eax,%es:(%rdi)
11: 8b 07 mov(%rdi),%eax
13: 85 c0 test %eax,%eax
15: 74 ed je 4 test+0x4
17: eb f4 jmpd test+0xd
19: f3 c3 repz retq
For the above sample code, local experimentation has shown than 4.5,
4.6 4.7 emit a string instruction without a 'cld' in the prologue.
Versions 4.4 4.8 do not emit a string instruction.
Most perturbations to the above sample code will change the output so
that no string instruction is emitted when using the defective
versions.
It is expected that a 'cld' instruction will be generated in the
function prolong whenever any string instruction is emitted by gcc when
the '-mcld' option has been provided.
[Bug target/57264] cld not emitted when string instructions used, and '-mcld' on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264 --- Comment #5 from thutt at vmware dot com --- (In reply to Uros Bizjak from comment #3) Author: uros Date: Mon May 13 17:14:26 2013 New Revision: 198837 URL: http://gcc.gnu.org/viewcvs?rev=198837root=gccview=rev Log: PR target/57264 Backport from mainline 2013-01-22 Jakub Jelinek ja...@redhat.com PR target/55686 * config/i386/i386.md (UNSPEC_STOS): New. (strset_singleop, *strsetdi_rex_1, *strsetsi_1, *strsethi_1, *strsetqi_1): Add UNSPEC_STOS. testsuite/ChangeLog: PR target/57264 * gcc.target/i386/pr57264.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr57264.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog Does the same error exist in the 4.8 branch, or any other forward moving branch?
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #21 from thutt at vmware dot com 2010-09-03 13:07 --- (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI
--- Comment #13 from thutt at vmware dot com 2009-02-10 14:34 --- (In reply to comment #12) (In reply to comment #11) Uros, how hard to support this in x86 backend? snip OTOH, constraints should be used to support correct register allocation for machine instructions, not to emulate ABI in order to support calls from inside asm statements. Please indulge me for a moment. What exactly is a call? Are you considering the only method of transferring control to be the standard 'near call' 'near ret' instructions on the x86? What about the following modes of transferring control to another address? int iret ret sysenter sysexit syscall sysret ud2 int3 jmp Then, what of these? lcall lret ljmp Every one of these is a method to transfer control to another address with a programmer-defined set of input register. More importantly, none of these are directly supported by gcc to invoke functions without resorting to inline assembly. If you're working on an operating system, a virtualization engine or some other embedded device you might need to transfer control using one of these methods. As a really simple example, consider a handler for a timer interrupt. Let's say that the prologue for the interrupt (written in assembly) handler storing all the machine registers into a data structure accessible from C. Then, the prologue transfers to the handler which is conveniently written in C. Wouldn't it be really nice if one could restore all the saved registers in C code using only inline assembly instruction? __asm__(iret : : force restoring registers saved in data structure); I'm confident you can see the advantage of doing this in C and letting the compiler deal with the bookkeeping details, rather than resorting to another assembly language function which does such a simple feat. I think I pretty clearly demonstrate here that calling other functions using the x86 architecture isn't as simple as assuming it's going only to be done with 'call', 'jmp' and 'ret', and many of those methods are not possible with straight C, even with gcc's helpful extensions. Should gcc prevent the developer from using the ABI just because the inline assembly wasn't meant to 'support calls from inside assembly statements'? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331
[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code
--- Comment #10 from thutt at vmware dot com 2009-01-22 13:59 --- (In reply to comment #7) The problem here is that you are using unitialized local register variables so the register allocator does not know any better. Anyways it works correctly on the trunk and I don't have any other compiler to test with really (this is both with and without IRA). First, what's the expansion of the TLA 'IRA'? Second, it makes no difference if all the locals are initialized, the compiler still incorrectly uses '%rbp'. Here is the disassembly of the source, with initializers for all local variables. 0010 test_function: 10: 48 89 5c 24 d0 mov%rbx,0xffd0(%rsp) 15: 48 89 6c 24 d8 mov%rbp,0xffd8(%rsp) 1a: 31 db xor%ebx,%ebx 1c: 4c 89 64 24 e0 mov%r12,0xffe0(%rsp) 21: 4c 89 6c 24 e8 mov%r13,0xffe8(%rsp) 26: 31 c9 xor%ecx,%ecx 28: 4c 89 74 24 f0 mov%r14,0xfff0(%rsp) 2d: 4c 89 7c 24 f8 mov%r15,0xfff8(%rsp) 32: 31 d2 xor%edx,%edx 34: 48 83 ec 38 sub$0x38,%rsp 38: 31 f6 xor%esi,%esi 3a: 48 8b 2d 00 00 00 00mov0(%rip),%rbp# 41 test_function+0x31 41: 48 8b 05 00 00 00 00mov0(%rip),%rax# 48 test_function+0x38 48: 31 ed xor%ebp,%ebp 4a: 31 ff xor%edi,%edi 4c: 45 31 c0xor%r8d,%r8d 4f: 45 31 c9xor%r9d,%r9d 52: 45 31 d2xor%r10d,%r10d 55: 45 31 dbxor%r11d,%r11d 58: 45 31 e4xor%r12d,%r12d 5b: 45 31 edxor%r13d,%r13d 5e: 45 31 f6xor%r14d,%r14d 61: 45 31 ffxor%r15d,%r15d 64: 0f 01 d8vmrun 67: 48 8b 3d 00 00 00 00mov0(%rip),%rdi# 6e test_function+0x5e 6e: 48 8d 75 f8 lea0xfff8(%rbp),%rsi 72: 48 39 fecmp%rdi,%rsi 75: 74 05 je 7c test_function+0x6c 77: e8 00 00 00 00 callq 7c test_function+0x6c 7c: 48 8b 5c 24 08 mov0x8(%rsp),%rbx 81: 48 8b 6c 24 10 mov0x10(%rsp),%rbp 86: 31 c0 xor%eax,%eax 88: 4c 8b 64 24 18 mov0x18(%rsp),%r12 8d: 4c 8b 6c 24 20 mov0x20(%rsp),%r13 92: 4c 8b 74 24 28 mov0x28(%rsp),%r14 97: 4c 8b 7c 24 30 mov0x30(%rsp),%r15 9c: 48 83 c4 38 add$0x38,%rsp a0: c3 retq Third, why does removing the unused function 'SetupVMCB' cause the compiler to generate different code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug c/38925] gcc ignores use of %rbp via assembly, generates bad code
--- Comment #5 from thutt at vmware dot com 2009-01-21 13:06 --- (In reply to comment #2) I think this code is undefined as you are using uninitialized variables for input of the inline-asm. I disagree. The registers are intended to have their *current* values saved across the 'vmrun' instruction. Since it's not possible to specify registers R8 through R15 in constraints, bug 16331 suggests this obtuse workaround. The intent of this code is twofold: demonstrate the assginment of two variables to '%rbp' and to show that it's not possible to show clobber an arbitrary set of registers. It does both well. Furthermore, if you'd take the code and compile with all the initializations, in place, you would have seen that it makes no difference whatsoever: two variables are assigned to '%rbp', just the same. But, all the initializations also make the code incorrect: the point is to either save all the registers across the 'vmrun' instruction, or to clearly indicate to the compiler that all the registers are clobbered at the end of the 'vmrun' instruction. -- thutt at vmware dot com changed: What|Removed |Added Component|inline-asm |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug c/38925] gcc ignores use of %rbp via assembly, generates bad code
--- Comment #6 from thutt at vmware dot com 2009-01-21 13:08 --- (In reply to comment #3) Also I think the inline-asm could be improved so that the inline-asm just marks the registers that are clobbered instead of doing the mess you are doing. Can you provide an example of how this can be done? The whole point of this report is to show that what you claim isn't actually possible. If it is possible, then that'd be a great thing -- but someone shoould update the docs to show that it is possible. Here's a wacky idea -- update the constraints system for the x86_64 target to allow any available (and specific) register to be constrained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug c/38925] New: gcc ignores use of %rbp via assembly, generates bad code
/*
* The below program demonstrates a defeciency with gcc's constraint
* syntax for 64-bit code: it's not possible to directly constrain an
* operand to a register in the range r8 through r15.
*
* Furthermore, it is not possible to use '%rbp' in a constraint.
*
* It has been shown that gcc can assign a local variable to a
* particular register
* (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331) but that does
* not properly work when %rbp is being used.
*
* The code below executes a 'vmrun' instruction. The intent of the
* inline assembly is to indicate that all the named registers can be
* clobbered by the 'vmrun' instruction.
*
* For simplicity, I've only set '_rbp' to zero to show that this
* local variable is assigned to '%rbp'.
*
* Here is a snippet of the code that is generated:
*
*
* 32: 48 8b 2d 00 00 00 00 mov0(%rip),%rbp# origRSP
* 39: 48 8b 05 00 00 00 00 mov0(%rip),%rax# guestVMCB
* 40: 31 ed xor%ebp,%ebp # zero _rbp
* 42: 0f 01 d8 vmrun
* 45: 48 8b 3d 00 00 00 00 mov0(%rip),%rdi# 4c
test_function+0x3c
* 4c: 48 8d 75 f8lea0xfff8(%rbp),%rsi # origRSP
- 8
*
*
* origRSP is allocated to '%rbp', and '_rsp' is allocated to the same
* register. Even though '_rsp' is set to zero and 'vmrun' can
* clobber all the named registers, the compiler still uses '%rbp' as
* if it were not modified at address 0x4c.
*
* Also, to add to the unusual behavior, removing the function
* 'SetupVMCB' causes the issue to vanish. SetupVMCB is unused.
*
* Using built-in specs.
* Target: x86_64-redhat-linux
* Configured with: ../configure --prefix=/usr \
* --mandir=/usr/share/man \
* --infodir=/usr/share/info \
* --enable-shared --enable-threads=posix \
* --enable-checking=release \
* --with-system-zlib --enable-__cxa_atexit \
* --disable-libunwind-exceptions --enable-libgcj-multifile \
* --enable-languages=c,c++,objc,obj-c++,java,fortran,ada \
* --enable-java-awt=gtk --disable-dssi --enable-plugin \
* --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre \
* --with-cpu=generic --host=x86_64-redhat-linux
* Thread model: posix
* gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
*
*
* To build:
*
* gcc -O2 -c -o main.o main.c
* objdump --disassemble main.o
*
*/
typedef unsigned long uint64;
typedef struct {
unsigned char pad[256];
uint64 rsp;
} VMCB;
void failure(uint64 a, uint64 b);
void SetupVMCB(uint64 rip, unsigned cpl);
uint64guestVMCB;
volatile VMCB mappedGuestVMCB;
static __attribute__((always_inline)) void
VMRUN(uint64 vmcb)
{
register unsigned long _rbx asm(rbx);
register unsigned long _rcx asm(rcx);
register unsigned long _rdx asm(rdx);
register unsigned long _rbp asm(rbp) = 0;
register unsigned long _rsi asm(rsi);
register unsigned long _rdi asm(rdi);
register unsigned long _r8 asm(r8);
register unsigned long _r9 asm(r9);
register unsigned long _r10 asm(r10);
register unsigned long _r11 asm(r11);
register unsigned long _r12 asm(r12);
register unsigned long _r13 asm(r13);
register unsigned long _r14 asm(r14);
register unsigned long _r15 asm(r15);
__asm__ __volatile__(vmrun
: +c (_rcx), +d (_rdx), +b (_rbx), +r (_rbp),
+S (_rsi), +D (_rdi), +r (_r8), +r (_r9),
+r (_r10), +r (_r11), +r (_r12), +r (_r13),
+r (_r14), +r (_r15)
: a (vmcb)
: memory);
}
int
test_function(void)
{
uint64 origRSP;
origRSP = mappedGuestVMCB.rsp;
VMRUN(guestVMCB);
{
uint64 _act = (mappedGuestVMCB.rsp);
uint64 _exp = (origRSP - sizeof(unsigned long));
if (_exp != _act) {
failure(_act, _exp);
}
}
return 0;
}
void
SetupVMCB(uint64 rip, unsigned cpl)
{
}
--
Summary: gcc ignores use of %rbp via assembly, generates bad code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug c/38925] gcc ignores use of %rbp via assembly, generates bad code
--- Comment #1 from thutt at vmware dot com 2009-01-20 21:27 --- See bug 16331 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug middle-end/17308] nonnull attribute not as useful as it could
--- Comment #4 from thutt at vmware dot com 2008-12-23 15:40 ---
/*
I concur with Ulrich, but three years on, using gcc 4.1.2.
Although a parameter which is marked with the 'nonnull' attribute
is demonstrably nonnull, and although the compiler recognizes it is
specifically NULL, no warning is emitted.
And, in fact, the compiler can end up generating bad code.
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man \
--infodir=/usr/share/info --enable-shared --enable-threads=posix \
--enable-checking=release --with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-libgcj-multifile \
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada \
--enable-java-awt=gtk --disable-dssi --enable-plugin \
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre \
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
gcc -c -o nonnull.o -O3 -Wall nonnull.c
nonnull.c: In function f1:
nonnull.c:52: warning: null argument where non-null required (argument
1)
nonnull.c:52: warning: null argument where non-null required (argument
2)
objdump --disassemble --reloc nonnull.o
nonnull.o: file format elf64-x86-64
Disassembly of section .text:
f1:
0: f3 c3 repz retq
2: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
If '-Wall' is not provided, the compiler does not even warn about
the NULL arguments. It hardly matters if the compiler warns or not,
the code that is generated for 'f1()' is simply bad code. But, when
no warning is provided by the compiler, the code is egregiously bad
-- anyone wondering why their program doesn't work may disassemble
the object module and see that nothing was emitted.
0010 f0:
10: ba 00 04 00 00 mov$0x400,%edx ; length = 1024
15: 31 f6 xor%esi,%esi ; second arg =
NULL
17: bf 00 00 00 00 mov$0x0,%edi ; first arg =
buf
1c: 48 c7 05 00 00 00 00movq $0x0,0(%rip); a = buf
23: 00 00 00 00
27: 48 c7 05 00 00 00 00movq $0x0,0(%rip); b = NULL
2e: 00 00 00 00
32: e9 00 00 00 00 jmpq memcpy
In this function, the compiler has automatically inlined
'copy_block()', and obviously determined that the second parameter
is NULL, as can be seen from addresses 15 27 -- but still no
warning is presented.
*/
#include stdlib.h
#include string.h
extern void *a;
extern void *b;
static void __attribute__((nonnull(1, 2)))
copy_block(void *dest, void *src)
{
memcpy(dest, src, 1024);
}
void f0(void)
{
static char buf[100];
a = buf;
b = NULL;
copy_block(a, b);
}
void f1(void)
{
copy_block(NULL, NULL);
}
--
thutt at vmware dot com changed:
What|Removed |Added
CC||thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #9 from thutt at vmware dot com 2008-12-23 15:44 --- (In reply to comment #1) The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. Witeness the last sentence. If this is the case, then might it not be better for the diagnostic to be an error rather than a warning? If it's a warning that is not even printed at the standard level of warnings, then it could be easily argued that the compiler is generating bad code. In other words, if a parameter does not meet a required precondition, then the compiler should issue an error always. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
--- Comment #2 from thutt at vmware dot com 2008-12-16 14:03 --- (In reply to comment #1) The reason why they are saved is so that you can have a good way of debugging noreturn functions. Can you please elaborate? How is saving these registers, which will never be restored, going to make it easier to debug noreturn functions? Can you please explain how the values in the saved registers are relevant to the 'noreturn' function? As far as I understand it, the callee saved registers are not used to pass any information to the callee, so I don't understand how saving them makes it easier to debug code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
[Bug c/38534] New: gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
/* When a function has been defined using the 'noreturn' attribute,
* there is no reason to save the callee-saved registers, mainly
* because the function is not going to return to the caller.
*
* This can save a few bytes of code generation for embedded-type
* applications which may use 'noreturn' functions to restart, for
* example, by jumping to a different address rather than returning to
* the caller.
*
* gcc information:
*
* Using built-in specs.
* Target: x86_64-redhat-linux
*
* Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
* --infodir=/usr/share/info --enable-shared
* --enable-threads=posix --enable-checking=release
* --with-system-zlib --enable-__cxa_atexit
* --disable-libunwind-exceptions
--enable-libgcj-multifile
* --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
* --enable-java-awt=gtk --disable-dssi --enable-plugin
*
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
* --with-cpu=generic --host=x86_64-redhat-linux
* Thread model: posix
* gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
*
* compilation disassembly information:
*
* gcc -c -O3 -o noreturn.o noreturn.c
* objdump --disassemble --reloc noreturn.o
*
* Notice in the disassembly of 'return_to_caller' that the
* registers pushed in the preamble are restored before
* returning. But, in the 'no_return_to_caller', they are not
* restored; since they are no restored, there is no reason to
* even save them.
*/
#include stdlib.h
extern unsigned array[1024][1024][1024];
extern unsigned value(int i, int j, int k);
#define LOOP_BODY \
do { \
unsigned i, j, k; \
for (i = 1024; i 0; --i) { \
for (j = 1024; j 0; --j) { \
for (k = 1024; k 0; --k) {\
array[i - 1][j - 1][k - 1] = value(i, j, k); \
} \
} \
} \
} while (0)
void
return_to_caller(int a, int b, int c, int d)
{
LOOP_BODY;
}
void __attribute__((noreturn))
no_return_to_caller(int a, int b, int c, int d)
{
LOOP_BODY;
while (1);
}
--
Summary: gcc 4.2.1 and above: No need to save called-saved
registers in 'noreturn' function
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
[Bug c/37148] New: -Wunintialized fails in the face of conditional assignment.
Although I demonstrated this using 4.1.2 on my host, it probably affects
other versions as well.
As the following code shows:
gcc -c -O1 -Wall -Werror uninitialized-warning.c
extern void called_function(unsigned p);
extern unsigned g;
void
f0(unsigned parm)
{
unsigned v;
if (parm == 0) {
v = 4;
}
called_function(v);
}
void
f1(unsigned parm)
{
unsigned v;
if (parm == 0) {
v = 4;
} else {
g = 0;
}
called_function(v);
}
void
f2(unsigned parm)
{
unsigned v;
called_function(v);
}
gcc does not produce the 'uninitialized' warning when the automatic
variable is conditionally assigned.
This gives a very bad false sense of security that the automatic
variables are indeed initialized.
--
Summary: -Wunintialized fails in the face of conditional
assignment.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37148
[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used unintialized' warning (CCP)
--- Comment #18 from thutt at vmware dot com 2008-08-18 13:55 --- This defect has been open nearly 4 years. Any hope of actually getting a fix commited? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #17 from thutt at vmware dot com 2007-03-27 13:49 --- In response to comment #16: I wouldn't call an inliner which inlines functions specifically marked as do not put this in '.text' as 'smart'. I'd use a more pejorative adjective, such as 'broken' or 'dumb'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #19 from thutt at vmware dot com 2007-03-27 14:44 --- I guess I need a bigger typeface because I don't see where it says '(the out-of-line copy)'. Or, perhaps, you've simply added that '(the out-of-line copy)' annotation yourself because that's what the code currently does, and because it suits your agenda. I guess you also felt free to interpret that it's ok to inline such functions, even though it doesn't say any such thing, and even though it goes against exactly what the 'section' attribute intends to do. But, as you stated, it's a waste of my time, and you folks obviously aren't going to treat this as a legitmate defect, so there's no point in continuing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] New: gcc should not inline functions with 'section' attribute
gcc should never inline functions which have a 'section' attribute set
on them.
If the section is placed at a specific location in memory via a linker
script, then the function will not be placed into its correct address,
and the resultant executable is incorrect.
gcc 4.1.1 will inline static function at -O1 and -O2, but not -O0 and
-O3; this can be seen by compiling the attached test program at
various optimization levels.
static int __attribute__((section(.special_section)))
special_function_0(void)
{
return 0;
}
int __attribute__((section(.special_section)))
special_function_1(void)
{
return 0;
}
int main(void)
{
special_function_0();
special_function_1();
return 0;
}
--
Summary: gcc should not inline functions with 'section' attribute
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #1 from thutt at vmware dot com 2007-03-26 15:08 --- Created an attachment (id=13288) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13288action=view) Simple Script which will build the original C source Simple Script which will build the original C source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #2 from thutt at vmware dot com 2007-03-26 15:09 --- Created an attachment (id=13289) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13289action=view) original source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #3 from thutt at vmware dot com 2007-03-26 15:09 --- Created an attachment (id=13290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13290action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #5 from thutt at vmware dot com 2007-03-26 15:40 --- I'm going to argue that comment #4 is incorrect. 1. This new behavior is a regression from previous versions of gcc. 2. The 4.1.1 compiler gets it right at -O0 and -O3. Previous versions of gcc which we've been using also get this right at all optimization levels. 3. The function is 'static', not '__attribute__((inline))'. The use of static doesn't implicitly give the optimizer permission to inline the function, it only declares the linkage to be 'internal'. However, if the compiler determines that the function meets certain criteria, such as being static and not having its address taken, then it *can* inline it. These 'certain criteria' should be expanded to include changing the section of a function; if it's not in the default text section, it shouldn't be inlined. (Of course, this shouldn't impact gcc's internal garbage collection mechanism of changing function data sections). In the actual implementation from which this test case was derived, the function *must* reside at a specific location in memory, but due to the inlining, it does not. This causes failures in the application. -- thutt at vmware dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #8 from thutt at vmware dot com 2007-03-26 15:57 --- Furthermore, 4. By placing the code in a different section, I'm instructing the the compiler to *not* put it in '.text'. By inlining it, it places it in '.text' despite my instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #12 from thutt at vmware dot com 2007-03-26 17:46 --- I respectfully submit that I think you guys are missing the point. The problem isn't that the compiler is inlining functions which are called once, the problem is that the compiler is inlining a function which I told it not to put into the '.text' section. I fully understand that there are many ways to make gcc *not* inline the function (noinline attribute, not static, call more than once, take it's address), and I've already done that. If I tell gcc to place code or data into another section, then it should do that -- always. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #14 from thutt at vmware dot com 2007-03-26 18:54 --- Why do you think sections are special? GCC does not know if a section is special or not and it really should not know. I don't necessarily think that sections are 'special', but since gcc has the capability to change the section, it seems like it ought to follow instructions. If that's not convincing enough, let me quote from the gcc 'info' page about function attributes: `section (SECTION-NAME)' Normally, the compiler places the code it generates in the `text' section. Sometimes, however, you need additional sections, or you need certain particular functions to appear in special sections. The `section' attribute specifies that a function lives in a particular section. For example, the declaration: extern void foobar (void) __attribute__ ((section (bar))); puts the function `foobar' in the `bar' section. Some file formats do not support arbitrary sections so the `section' attribute is not available on all platforms. If you need to map the entire contents of a module to a particular section, consider using the facilities of the linker instead. I don't think that I can be more clear than this text -- placing an __attribute__(section (bar)) will place the attributed function into the 'bar' section. By inlining the function, it's *not* placing it into the 'bar' section. There are many reasons why a function might need to be placed into a special section but those reasons are really moot since the documentation of the compiler states exactly what the section attribute is supposed to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31327] New: Cast on expression using induction variable not honored at O1 and O2
] = 127 v = 127 fails_1_at_O1_O2: arr[123] = -128 v = 128 fails_1_at_O1_O2: arr[124] = -127 v = 129 fails_1_at_O1_O2: arr[125] = -126 v = 130 fails_1_at_O1_O2: arr[126] = -125 v = 131 works_at_all_O_levels: arr[118] = 123v = 123 works_at_all_O_levels: arr[119] = 124v = 124 works_at_all_O_levels: arr[120] = 125v = 125 works_at_all_O_levels: arr[121] = 126v = 126 works_at_all_O_levels: arr[122] = 127v = 127 works_at_all_O_levels: arr[123] = -128v = -128 works_at_all_O_levels: arr[124] = -127v = -127 works_at_all_O_levels: arr[125] = -126v = -126 works_at_all_O_levels: arr[126] = -125v = -125 Executing with optimization -O2 fails_0_at_O1_O2: arr[118] = 123 (char)(i + 5) = 123 fails_0_at_O1_O2: arr[119] = 124 (char)(i + 5) = 124 fails_0_at_O1_O2: arr[120] = 125 (char)(i + 5) = 125 fails_0_at_O1_O2: arr[121] = 126 (char)(i + 5) = 126 fails_0_at_O1_O2: arr[122] = 127 (char)(i + 5) = 127 fails_0_at_O1_O2: arr[123] = -128 (char)(i + 5) = 128 fails_0_at_O1_O2: arr[124] = -127 (char)(i + 5) = 129 fails_0_at_O1_O2: arr[125] = -126 (char)(i + 5) = 130 fails_0_at_O1_O2: arr[126] = -125 (char)(i + 5) = 131 fails_1_at_O1_O2: arr[118] = 123 v = 123 fails_1_at_O1_O2: arr[119] = 124 v = 124 fails_1_at_O1_O2: arr[120] = 125 v = 125 fails_1_at_O1_O2: arr[121] = 126 v = 126 fails_1_at_O1_O2: arr[122] = 127 v = 127 fails_1_at_O1_O2: arr[123] = -128 v = 128 fails_1_at_O1_O2: arr[124] = -127 v = 129 fails_1_at_O1_O2: arr[125] = -126 v = 130 fails_1_at_O1_O2: arr[126] = -125 v = 131 works_at_all_O_levels: arr[118] = 123v = 123 works_at_all_O_levels: arr[119] = 124v = 124 works_at_all_O_levels: arr[120] = 125v = 125 works_at_all_O_levels: arr[121] = 126v = 126 works_at_all_O_levels: arr[122] = 127v = 127 works_at_all_O_levels: arr[123] = -128v = -128 works_at_all_O_levels: arr[124] = -127v = -127 works_at_all_O_levels: arr[125] = -126v = -126 works_at_all_O_levels: arr[126] = -125v = -125 Executing with optimization -O3 fails_0_at_O1_O2: arr[118] = 123 (char)(i + 5) = 123 fails_0_at_O1_O2: arr[119] = 124 (char)(i + 5) = 124 fails_0_at_O1_O2: arr[120] = 125 (char)(i + 5) = 125 fails_0_at_O1_O2: arr[121] = 126 (char)(i + 5) = 126 fails_0_at_O1_O2: arr[122] = 127 (char)(i + 5) = 127 fails_0_at_O1_O2: arr[123] = -128 (char)(i + 5) = -128 fails_0_at_O1_O2: arr[124] = -127 (char)(i + 5) = -127 fails_0_at_O1_O2: arr[125] = -126 (char)(i + 5) = -126 fails_0_at_O1_O2: arr[126] = -125 (char)(i + 5) = -125 fails_1_at_O1_O2: arr[118] = 123 v = 123 fails_1_at_O1_O2: arr[119] = 124 v = 124 fails_1_at_O1_O2: arr[120] = 125 v = 125 fails_1_at_O1_O2: arr[121] = 126 v = 126 fails_1_at_O1_O2: arr[122] = 127 v = 127 fails_1_at_O1_O2: arr[123] = -128 v = -128 fails_1_at_O1_O2: arr[124] = -127 v = -127 fails_1_at_O1_O2: arr[125] = -126 v = -126 fails_1_at_O1_O2: arr[126] = -125 v = -125 works_at_all_O_levels: arr[118] = 123v = 123 works_at_all_O_levels: arr[119] = 124v = 124 works_at_all_O_levels: arr[120] = 125v = 125 works_at_all_O_levels: arr[121] = 126v = 126 works_at_all_O_levels: arr[122] = 127v = 127 works_at_all_O_levels: arr[123] = -128v = -128 works_at_all_O_levels: arr[124] = -127v = -127 works_at_all_O_levels: arr[125] = -126v = -126 works_at_all_O_levels: arr[126] = -125v = -125 -- Summary: Cast on expression using induction variable not honored at O1 and O2 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thutt at vmware dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #1 from thutt at vmware dot com 2007-03-23 15:02 --- Created an attachment (id=13265) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13265action=view) Simple script to build test program at all optimization levels -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #2 from thutt at vmware dot com 2007-03-23 15:03 --- Created an attachment (id=13266) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13266action=view) Simple source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #3 from thutt at vmware dot com 2007-03-23 15:03 --- Created an attachment (id=13267) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13267action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #15 from thutt at vmware dot com 2007-03-23 15:51 --- In regards to comment #13: In what tarball is this defect fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
