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

operations 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.

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

rg ReportedBy: drepper 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

oduct: 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

--- 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

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

nedTo: 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/25522] zero-initialized constants are place in .bss

--- 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 rtl-optimization/25609] New: too agressive printf optimization

Version: 4.0.2 Status: 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

--- 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

--- 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

--- 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

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

--- 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 R

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

--- 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. g

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

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-* x86_64-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840

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

--- 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 instru

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

--- 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'

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

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

-- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23221

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

dot gnu dot org 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 target/14625] tail call optimization missed

--- 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_functi

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

tion AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drepper at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30306