[Bug c/41516] New: sizeof(int) is not a compile time constant??
the attached testcase shows that sizeof(int) is not identical to a compile time constant of 4. the first testcase uses sizeof(int) as a bound check, and somehow the call to the non-existing function is not optimized out. in the second testcase sizeof(int) is replaced by 4 and the optimization suddenly works. -- Summary: sizeof(int) is not a compile time constant?? Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41516
[Bug c/41516] sizeof(int) is not a compile time constant??
--- Comment #1 from arjan at linux dot intel dot com 2009-09-30 09:50 --- Created an attachment (id=18672) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18672action=view) the failing case with sizeof(int) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41516
[Bug c/41516] sizeof(int) is not a compile time constant??
--- Comment #2 from arjan at linux dot intel dot com 2009-09-30 09:51 --- Created an attachment (id=18673) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18673action=view) sizeof(int) replaced by 4 and it suddenly optimizes just fine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41516
[Bug c/41477] New: gcc does not optimize a case that it should to make __builtin_object_size() more useful
(see attached testcases; testcase.c shows the problem, testcase2.c shows that reorging the code works around it) it appears that gcc does not realize that after if (variable 1 || variable 10) return -1; the variable is in the range [1..10], likely because the execution of the second check is optional due to the ||. in a typical __builtin_object_size() scenario, like if (__builtin_object_size(foo) variable) some_error(); where foo is 10 bytes in size, this means the check does not get optimized out. -- Summary: gcc does not optimize a case that it should to make __builtin_object_size() more useful Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41477
[Bug c/41477] gcc does not optimize a case that it should to make __builtin_object_size() more useful
--- Comment #2 from arjan at linux dot intel dot com 2009-09-26 18:02 --- Created an attachment (id=18659) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18659action=view) testcase that shows a slight reorder of the code works around the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41477
[Bug c/37921] New: __builtin_constant_p seems to be giving false positives
__builtin_constant_p seems to be giving a false positive as shown by the testcase that I'll attach to this bug. This is causing a warning in the Linux kernel build -- Summary: __builtin_constant_p seems to be giving false positives Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921
[Bug c/37921] __builtin_constant_p seems to be giving false positives
--- Comment #1 from arjan at linux dot intel dot com 2008-10-26 18:17 --- Created an attachment (id=16553) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16553action=view) test case for bug 37921 gcc -c -Wall -Os -fno-strict-aliasing -o fadt.o fadt.c leads to: fadt.c: In function acpi_tb_create_local_fadt: fadt.c:132: warning: array subscript is above array bounds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921
[Bug target/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #4 from arjan at linux dot intel dot com 2006-07-29 07:46 --- fixed in current SVN -- arjan at linux dot intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/28281] New: gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
Userspace and kernel space use a different segment register for TLS access in x86_64. (This is so that a syscall doesn't need to switch these registers most of the time, so good for performance) This means that the kernel cannot use -fstack-protector currently, which is sad since today another buffer overflow has been found in the linux kernel. The solution is quite simple, and I will attach a patch to fix this next; just use a different segement register for the mc_kernel model. (the patch is trivial; it copies a line and changes a few characters in it, and then places an if around it) -- Summary: gcc uses the wrong segment register for TLS access for - fstack-protector in kernel mode Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #1 from arjan at linux dot intel dot com 2006-07-06 09:24 --- Created an attachment (id=11839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11839action=view) patch to fix this issue, including a testcase patch + testcase for this issue 2006-07-06 Arjan van de Ven [EMAIL PROTECTED] * config/i386/i386.md: add conditonal for kernel side stack-protector -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #2 from arjan at linux dot intel dot com 2006-07-06 09:49 --- Created an attachment (id=11842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11842action=view) updated patch updated patch; it helps if I send the non-test version of the testsuite test so that it actually tests the right behavior -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #3 from arjan at linux dot intel dot com 2006-07-06 11:08 --- Created an attachment (id=11844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11844action=view) updates with Jakub's comments updates with jakubs comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/26457] New: -fstack-protector leaks the upper bits of RAX
The following code snippet, compiled with -Os -fstack-protector:
#include string.h
int StringChecksum(char *s)
{
char buffer[2048];
int i;
int checksum = 0;
memset(buffer, 0, 2048);
strcpy(buffer, s);
for (i=0; i2048; i++)
checksum += buffer[i];
return checksum;
}
leads to the following snippet of assembly for the part where gcc puts the
canary value on the stack: (part of the full assembly of the function)
movq%rsp, %rdi
movq%fs:40, %rax
movq%rax, 2056(%rsp)
xorl%eax, %eax
callmemset
the key instruction for this bug is the xorl %eax, %eax. The intent of that
instruction seems to be to not leak the canary value into the actual function
code; however the canary value is 64 bits and in RAX, while the XOR is only
zeroing the lower 32 bits. For consistency and information security, this XOR
should, I think, clear all of RAX (which is same-cost anyway both in size and
execution)
--
Summary: -fstack-protector leaks the upper bits of RAX
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arjan at linux dot intel dot com
GCC host triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
