--- Comment #5 from adam at consulting dot net dot nz 2010-09-13 00:24
---
Andrew Pinski wrote:
This is caused by revision 160124:
Not really, it is a noreturn function so the behavior is correct for our
policy of allowing a more correct backtrace for noreturn functions
--- Comment #2 from adam at consulting dot net dot nz 2010-09-11 11:15
---
GCC snapshot has regressed compared to gcc-4.5:
#include assert.h
#include stdint.h
#define LIKELY(x) __builtin_expect(!!(x), 1)
#define UNLIKELY(x) __builtin_expect(!!(x), 0)
register uint32_t *Iptr
comparisons
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
http
--- Comment #3 from adam at consulting dot net dot nz 2010-08-17 06:28
---
AMD64 non-large code model. Functions occupy lower 2GB of the address space.
Cannot compile an array of 32-bit function addresses:
#include stddef.h
#include stdint.h
#include stdio.h
void fn() {
printf
dot org
ReportedBy: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45296
--- Comment #3 from adam at consulting dot net dot nz 2010-08-16 23:41
---
Why is this invalid gnu99 code?
How does one reserve x87 stack values as global register variables so that one
may use gnu99 operators such as + upon those global register variables instead
of having to resort
--- Comment #2 from adam at consulting dot net dot nz 2010-07-13 23:19
---
This issue needs to be revisited with the advent of asm goto:
__attribute__ ((noreturn)) void noreturn_via_asm_goto() {
loop:
asm goto (jmp %l[loop]\n : : : : loop);
}
int main() {}
$ gcc-4.5 -std=gnu99
--- Comment #1 from adam at consulting dot net dot nz 2010-06-07 05:35
---
Example-specific workaround discovered for global register variable
pessimisation with recent versions of GCC:
void push_flag_into_global_reg_var(uint64_t a, uint64_t b) {
uint64_t flag = (a==b
: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
--- Comment #4 from adam at consulting dot net dot nz 2010-01-05 04:17
---
/* Workaround discovered! */
void test_int_vectors_containing_fp_data_using_local_reg_var_overlay() {
//create local register variables of the required floating point type
//(for the same global register
dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42595
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
--- Comment #3 from adam at consulting dot net dot nz 2010-01-03 23:20
---
This is a demo of poor code generation with XMM global register variables
(hardregs) and the vector extensions. Intrinsics are too low level. The
vector extensions can continue to work on a platform without x86
: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
GCC build triplet: core2
GCC host triplet: linux
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40170
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
GCC host triplet: Debian Linux
GCC target
15 matches
Mail list logo
