[Bug middle-end/39840] New: Non-optimal (or wrong) implementation of SSE intrinsics

2009-04-21 Thread drepper at redhat dot com
intrinsics Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com GCC target triplet: i?86

[Bug middle-end/39840] Non-optimal (or wrong) implementation of SSE intrinsics

2009-04-21 Thread drepper at redhat dot com
--- Comment #2 from drepper at redhat dot com 2009-04-21 19:37 --- [I couldn't attach the code as an attachment, bugzilla has a bug.] The program below has to be compiled with -mavx to allow the AVX intrinsics being used. But this also triggers using the use of the vmovss instruction

[Bug middle-end/39840] Non-optimal (or wrong) implementation of SSE intrinsics

2009-04-21 Thread drepper at redhat dot com
--- Comment #4 from drepper at redhat dot com 2009-04-21 19:51 --- (In reply to comment #3) Gcc 4.4 and above supports different target options on the function level but not on a basic block level. So you can create an interneral version for AVX. This doesn't work either. Aside

[Bug target/34475] New: TLS and PIE don't mix on x86-64

2007-12-14 Thread drepper at redhat dot com
ReportedBy: drepper at redhat dot com GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34475

[Bug tree-optimization/30306] New: printf-puts optimization prevented by %%

2006-12-26 Thread drepper at redhat dot com
: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30306

[Bug rtl-optimization/25609] New: too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609

[Bug rtl-optimization/25609] too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
--- Comment #4 from drepper at redhat dot com 2005-12-30 23:06 --- No, it's *NOT* undefined. The libc interface decides what is defined and what is not and it is *EXPLICITLY* documented that NULL pointers are printed as (null). The standard might leave it undefined but this does

[Bug rtl-optimization/25609] too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
--- Comment #6 from drepper at redhat dot com 2005-12-30 23:08 --- This is NOT a dup of 15574. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609

[Bug rtl-optimization/25609] too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
--- Comment #8 from drepper at redhat dot com 2005-12-30 23:14 --- That is true but GCC is a C compiler and not a glibc implemention C compiler. This doesn't mean anything. As soon as you configure gcc to target it to Linux the behavior of the runtime is as defined by the C library

[Bug rtl-optimization/25609] too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
--- Comment #10 from drepper at redhat dot com 2005-12-30 23:44 --- glibc *is* the world as far as Linux is concerned. You consistently and deliberately misinterpret what I write: I'm not talking about any platform which does not use glibc or glibc's behavior. And RTH already

[Bug rtl-optimization/25609] too agressive printf optimization

2005-12-30 Thread drepper at redhat dot com
--- Comment #12 from drepper at redhat dot com 2005-12-31 00:19 --- That is not true at all and you know that. There is uclibc. Now you've completely given up on logic? First of all, uclibc and whatever other libc immitation is out there does not define the linux API. glibc

[Bug middle-end/25522] zero-initialized constants are place in .bss

2005-12-25 Thread drepper at redhat dot com
--- Comment #5 from drepper at redhat dot com 2005-12-26 05:52 --- What happens if you use -fno-common? In this case the variable gets the index of .bss in the symbol table instead of using SHN_COMMON. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25522

[Bug c++/25541] New: invalid warning about unused variable

2005-12-22 Thread drepper at redhat dot com
: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25541

[Bug middle-end/25521] New: change semantics of const volatile variables

2005-12-21 Thread drepper at redhat dot com
at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521

[Bug middle-end/25522] New: zero-initialized constants are place in .bss

2005-12-21 Thread drepper at redhat dot com
: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25522

[Bug middle-end/25521] change semantics of const volatile variables

2005-12-21 Thread drepper at redhat dot com
--- Comment #2 from drepper at redhat dot com 2005-12-21 19:38 --- Using gcc's section attributes won't fully work either. Using __attribute((section(.rodata))) is OK in the compiler, although the assembler (correctly) complaints. But what is really needed is __attribute((section

[Bug tree-optimization/24696] New: missing optimization in comparison of results of bit operations

2005-11-06 Thread drepper at redhat dot com
Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla

[Bug middle-end/23221] New: -fstack-protector does not protect tail call functions

2005-08-03 Thread drepper at redhat dot com
-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23221

[Bug middle-end/23221] -fstack-protector does not protect tail call functions

2005-08-03 Thread drepper at redhat dot com
-- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23221

[Bug target/14625] tail call optimization missed

2005-01-31 Thread drepper at redhat dot com
--- Additional Comments From drepper at redhat dot com 2005-01-31 23:34 --- /* If this function requires more stack slots than the current function, we cannot change it into a sibling call. */ || args_size.constant current_function_args_size