[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #9 from t dot artem at mailcity dot com 2009-07-07 18:45 --- Qt 4.5.2 /lib directory (without *.debug files) occupies GCC 4.2.4: 43,649,379 bytes in 107 files GCC 4.4.0: 46,544,895 bytes in 107 files I don't like it at all. Compilation flags are still the same: -march=pentium2 -O2 -pipe -ftree-vectorize I hope GCC 4.5.0 will become sane again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #18 from t dot artem at mailcity dot com 2009-08-08 14:14 --- (In reply to comment #16) > > This is not a simple testcase. A simple testcase is a sufficiently small > self-contained compilable code that shows the problem in a way that can be > reliably and consistently reproduced. The ideal testcase would be the smallest > possible still showing the problem but anything below 100 lines of > preprocessed > code is probably small enough. > OK, let's be blunt. 99% of applications and libraries (that I use regularly) compiled with GCC >= 4.3 have bigger (binary code) sizes and lower speed. You can _easily_ check it on your own. And I cannot come up with a really simple testcase because a new compilation infrastructure introduced in GCC 4.3 made everything not so brilliant. The last but not the least - is that I'm not a developer at all, I have no knowledge of assembler, thus I have no ability to analyze code produced by different GCC versions. All I see is the end result and it's far from being remarkable. It seems like GCC developers are busy implementing new features forgetting about the core mission of any compiler - creating the most efficient code for all supported architectures. I'm closing this bug since I feel no one will step up to even confirm it. -- t dot artem at mailcity dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #16 from t dot artem at mailcity dot com 2007-02-02 17:02 --- Since GCC 4.1.2 RC1 is already out, does that mean that this bug is postponed till GCC 4.1.3/4.2.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #23 from t dot artem at mailcity dot com 2008-03-09 19:03 --- Since GCC 4.3.0 is out and this bug is no longer reproducible I suppose it's worth marking this bug as FIXED. Wow, it took exactly two years to fix this bug :-) -- t dot artem at mailcity dot com changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu-gcc |i686-pc-linux-gnu Known to fail|4.2.0 |4.1.2 4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug regression/35671] New: [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
With the same CFLAGS/CXXFLAGS, GCC 4.3.0 produces the code which is on average 1-5% bigger then the code produced by GCC 4.2.3. My usual c|c++ flags are: -march=pentium2 -O2 -pipe -ftree-vectorize I've tested wine 0.9.58 and KDE 3.5.9. -- Summary: [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t dot artem at mailcity dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug c++/35672] New: GCC 4.2.3 ICE on valid code: KDE 3.5.9 libdjvu compilation fails
/bin/sh ../../../../libtool --silent --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../../../.. -I../../../.. -I/opt/kde3/include
-I/usr/lib/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -march=pentium2 -O2 -mmmx -pipe
-Wno-unused-variable -ftree-vectorize -ftree-loop-linear -fivopts
-Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-deprecated -Wformat-security
-Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -MT IW44Image.lo -MD -MP -MF .deps/IW44Image.Tpo -c -o
IW44Image.lo IW44Image.cpp
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
... skipped ...
IW44Image.cpp: In static member function 'static void
IW44Image::Transform::Decode::YCbCr_to_RGB(GPixel*, int, int, int)':
IW44Image.cpp:1905: internal compiler error: Segmentation fault
GCC 4.3.0 works OK here.
Without '-fivopts' the code compiles just fine.
--
Summary: GCC 4.2.3 ICE on valid code: KDE 3.5.9 libdjvu
compilation fails
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t dot artem at mailcity dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35672
[Bug c++/35672] GCC 4.2.3 ICE on valid code: KDE 3.5.9 libdjvu compilation fails
--- Comment #1 from t dot artem at mailcity dot com 2008-03-23 00:11 --- Created an attachment (id=15364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15364&action=view) Compilation directory with .ii and .s output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35672
[Bug c++/35672] GCC 4.2.3 ICE on valid code: KDE 3.5.9 libdjvu compilation fails
--- Comment #2 from t dot artem at mailcity dot com 2008-03-23 00:12 --- Sorry, a flag to blame is '-ftree-loop-linear' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35672
[Bug regression/35671] [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
--- Comment #2 from t dot artem at mailcity dot com 2008-03-24 22:24 --- I'll check this out very soon - at least on Wine sources. Recompiling KDE isn't a task I'm very found of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug regression/35671] [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
--- Comment #3 from t dot artem at mailcity dot com 2008-03-24 23:01 --- counting all .so and .a files in lib/wine directory: Without -ftree-vectorize: GCC 4.2.3: 46,884,566 bytes in 305 files GCC 4.3.0: 47,375,178 bytes in 305 files With -ftree-vectorize: GCC 4.2.3: 46,889,486 bytes in 305 files GCC 4.3.0: 47,397,130 bytes in 305 files It's not like too much to care about. I have to test using different sources. The truth is that Windows archivers work slower in Wine compiled using GCC 4.3. That was the real grief. -- t dot artem at mailcity dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug c/39741] New: [BUG or NOT?] Segmentation fault on valid code
Compile the following code without any optimizations:
#include
int main(int argc, char *argv[])
{
char a[900];
printf("gcc is wonderful\n");
}
like gcc test.c -o test.o
./test
Segmentation fault
Is it a bug? Can anyone give an insight why such a code segfaults?
--
Summary: [BUG or NOT?] Segmentation fault on valid code
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t dot artem at mailcity dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39741
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #4 from t dot artem at mailcity dot com 2009-04-18 01:44 --- Test configuration: Software: Linux kernel 2.6.28.9 x86, GCC 4.2.4, GCC 4.4.0 RC, http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz Hardware: AMD64 Dual Core CPU 5600, 1MB x 2 level 2 cache RAM: DDR2 800MHz 4GB unrarsrc-3.8.5.tar.gz compiled binary (compilation flags: -march=pentium2 -O2 -ftree-vectorize): GCC 4.2.4: 180492 bytes GCC 4.4.0: 196288 bytes Uncompressing 1GB archive (several hundreds WAV files): time rar-4.2.4 t -inul archive.rar real1m18.413s user1m17.758s sys 0m0.580s time rar-4.4.0 t -inul archive.rar real1m28.021s user1m27.344s sys 0m0.627s (average results for five runs - disk IO has zero effect, since file resides on RAM disk). Summary: 4.4.x binary is 9% larger and produces code which runs 14% slower. -- t dot artem at mailcity dot com changed: What|Removed |Added Severity|minor |major Status|RESOLVED|UNCONFIRMED Known to fail||4.4.0 4.3.3 Known to work||4.2.4 Resolution|WONTFIX | Summary|[POSSIBLY NOT A BUG] GCC|GCC 4.4.x vs. 4.2.x |4.3.0 vs. 4.2.3 observations|performance regression Version|4.3.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #6 from t dot artem at mailcity dot com 2009-04-18 08:18 --- Many Linux distros compile binaries for a common lowest denominator so that you could run a distro on very old computers and CPUs - their developers in most cases choose -march=i686 or -march=i586. I compile binaries which I have to run on very old computers like Pentium 2, that's why I chose -march=pentium2 in the first place. Let's go back to the results: -march=i386 -O2 -pipe -ftree-vectorize unrar-424 size: 169384 time: 1m34.372s unrar-440 size: 175836 time: 1m32.014s Without CPU optimizations a binary produced by GCC 4.4.0 is larger but a bit faster. -march=native -O2 -pipe -ftree-vectorize unrar-424 size: 180488 time: 1m17.608s unrar-440 size: 188348 time: 1m27.211s With native CPU optimizations a binary produced by GCC 4.4.0 is again larger but noticeably slower. Pentium2 results have been already posted. This is the second major release of GCC which produces subpar results ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #8 from t dot artem at mailcity dot com 2009-04-19 13:51 --- If anyone cares to repeat my test results, here's a simple test case: 1) Obtain a large enough collection of WAV files (however I'm sure all other compressible material will also fit this test). If you have wine emulator installed you can get many large wav files by running this application (http://www.scene.org/file.php?file=/demos/groups/farb-rausch/fr-028.zip&fileinfo) - "record" all files to the same folder. 2) Compress your test folder with RAR archiver (http://rarlabs.com/rar/rarlinux-3.8.0.tar.gz) using these parameters: rar -r -m5 -mdG arhive_name.rar folder 3) Compile unrar (http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz) with the already given parameters. See :) (In reply to comment #7) > For better speed with -march=pentium2 you should add -mtune=generic which > will use only pentium2 features but tunes the code to not pessimize newer > processors. > As you can see 1) GCC 4.2 "pessimizes" code less than GCC 4.4, and 2) I'm sure no new pentium2 optimizations have been introduced for the last two years - so I'm sure general -O2 code produced by GCC 4.4 (and 4.3) is less optimized than code produced by GCC 4.2. At least it's quite obvious than most binaries are larger - but performance benefit is not so clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #18 from t dot artem at mailcity dot com 2007-05-18 08:32 --- As for GCC 4.2.0 the bug is still relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #67 from t dot artem at mailcity dot com 2010-04-17 14:28 --- Am I right assuming that GCC 4.5 is also affected by this bug? Is this bug going to be resolved? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug inline-asm/45160] New: [GCC 4.4.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
A testcase for x86 architecture (Intel Core i5 CPU here):
1) Download
http://sourceforge.net/projects/faac/files/faad2-src/faad2-2.6/faad2-2.6.1.tar.gz/download
2) Build it using these commands
perl -pi -e 's|dnl AC_PROG_CXX|AC_PROG_CXX|' configure.in
autoreconf -vif
configure --disable-static
using GCC 4.2.4 and GCC 4.4.x
3) faad binary compiled with GCC 4.4.x will fail to properly decode some AAC
files (a sample file can be downloaded here
http://bugzilla.mplayerhq.hu/attachment.cgi?id=651 )
faad -o outfile.wav out.aac
...
Decoding out.aac took: 0.21 sec. 285.83x real-time. (GCC 4.2.x)
Decoding out.aac took: 1.55 sec. 38.72x real-time. (GCC 4.4.x)
So, we have two bugs here:
1) faad2's AAC decode algorithm fails to work correctly under GCC 4.4.x (even
with gcc -O2 -march=i686).
3) faad2's AAC decode algorithm compiled with GCC 4.4.x works an order of
magnitude slower than the same code code compiled using GCC 4.2.x.
--
Summary: [GCC 4.4.x regression] Invalid assembly code is
generated for x86 architecture for faad2 library (AAC
decode algorithm)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t dot artem at mailcity dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [GCC 4.4.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #1 from t dot artem at mailcity dot com 2010-08-02 00:09 --- faad2 2.7.0 exhibits the same misbehavior, you can download it here: http://downloads.sourceforge.net/faac/faad2-2.7.tar.bz2 No extra commands are required for compilation, just ./configure && make --- P.S. You may want to use ./configure --enable-static --disable-shared in order to get a single binary which doesn't use any external libraries (thus it will be easier to verify the bug). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [GCC 4.4.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #2 from t dot artem at mailcity dot com 2010-08-02 00:31 --- Created an attachment (id=21368) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21368&action=view) faad2 2.7.0 complete sources with -save-temps Complete sources with -save-temps for GCC 4.2.4 and GCC 4.4.4. The same compilation flags: -march=i686 -O2 -pipe -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #3 from t dot artem at mailcity dot com 2010-08-02 13:09 --- I've just tested GCC 4.5.1 and it also miscompiles the source code. -- t dot artem at mailcity dot com changed: What|Removed |Added Summary|[GCC 4.4.x regression] |[4.4.x/4.5.x regression] |Invalid assembly code is|Invalid assembly code is |generated for x86 |generated for x86 |architecture for faad2 |architecture for faad2 |library (AAC decode |library (AAC decode |algorithm) |algorithm) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #4 from t dot artem at mailcity dot com 2010-08-02 13:10 --- Created an attachment (id=21369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21369&action=view) faad2 2.7.0 complete sources with -save-temps for GCC 4.5.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #5 from t dot artem at mailcity dot com 2010-08-02 13:15 --- I've found the culprit (or better say mplayer developer hinted), it is -fstrict-aliasing optimization. With -fno-strict-aliasing GCC 4.4.x and 4.5.x produce proper code. Please, advise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #7 from t dot artem at mailcity dot com 2010-08-02 15:49 --- (In reply to comment #6) > Why CC me? I have no clue about faad2, the strict-aliasing thing hints > at errors in faad2, not gcc. > Richard, I don't know who is who amongst GCC developers, but you are a prominent person, so I thought you know someone who can help shed light on this issue. Like I said GCC 4.2.x has no problems compiling this library, so I have no idea who to blame and who else I should get in touch with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #9 from t dot artem at mailcity dot com 2010-08-02 20:27 --- The culprit is the ic_predict.c file. When I compile it with -fno-strict-aliasing (while everything else is being compiled with -fstrict-aliasing) libfaad works correctly. These are the warnings which I get from GCC: ic_predict.c: In function 'flt_round': ic_predict.c:58: warning: dereferencing type-punned pointer will break strict-aliasing rules ic_predict.c:58: warning: dereferencing type-punned pointer will break strict-aliasing rules ic_predict.c:58: warning: dereferencing type-punned pointer will break strict-aliasing rules ic_predict.c:60: warning: dereferencing type-punned pointer will break strict-aliasing rules ic_predict.c: In function 'ic_prediction': ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here ic_predict.c:78: warning: dereferencing pointer 'tmp' does break strict-aliasing rules ic_predict.c:77: note: initialized from here Maybe GCC developers could devise a patch for this file because http://www.audiocoding.com/faad2.html site seems to be dead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug c/45312] New: GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
This bug is described here: https://bugzilla.kernel.org/show_bug.cgi?id=16612 In two words: this patch: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=568132624386f53e87575195d868db9afb2e9316 makes kernel 2.6.35.2 unusable on my PC. The particular file that gets miscompiled is this one: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=blob;f=arch/x86/include/asm/cmpxchg_32.h;h=c1cf59d72f096e3825010681889eb6625c662d16;hb=HEAD GCC 4.5.1 is not affected by this bug. -- Summary: GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t dot artem at mailcity dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
--- Comment #3 from t dot artem at mailcity dot com 2010-08-18 04:05 --- OK, then I'm closing this bug report, since I don't have enough experience to actually find a file that is being miscompiled. (And according to Linus it can be any out of dozens). -- t dot artem at mailcity dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
--- Comment #5 from t dot artem at mailcity dot com 2010-08-18 05:11 --- This crash occurs upon loading modules, so it's *very* difficult to trace/pinpoint it. Most likely no kernel options have any effect on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
--- Comment #7 from t dot artem at mailcity dot com 2010-08-18 20:00 --- I bet this bug can be triggered in a VM (e.g. in VirtualBox) too, so I'll try to debug it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)
--- Comment #11 from t dot artem at mailcity dot com 2010-09-06 20:19 --- (In reply to comment #9) > Maybe GCC developers could devise a patch for this file because > http://www.audiocoding.com/faad2.html site seems to be dead. > (In reply to comment #10) > Not a gcc bug. > FAAD developers don't answer my e-mails, so what I can do? Resort to compile FAAD library using a specially compiled GCC? What about other less experienced users? There just a few warnings which I suppose can be easily resolved ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45160
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #69 from t dot artem at mailcity dot com 2010-04-29 02:12 --- (In reply to comment #64) > Subject: Bug 40838 > This patch is not sufficient, some applications still crash after I've applied it to GCC 4.4 branch (to be more precise gcc-4.4-20100427.tar.bz2). I still wonder how GCC 4.4.x and 4.5.0 were ever released, to me it's a zero priority bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #71 from t dot artem at mailcity dot com 2010-04-29 07:24 --- (In reply to comment #70) No, I haven't used -mstackrealign as I presumed that the patch is sufficient - and since you make me sound like I'm wrong, then the patch is also wrong, since GCC must be producing a working code with no extra compilation flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #74 from t dot artem at mailcity dot com 2010-04-29 08:29 --- Guys, you are talking in riddles. There's a fact: with -msse2 -O2 -m32 flags GCC generate bad code for some properly coded applications, so I wonder what users are supposed to do. There are already six duplicates of this bug in Wine's bugzilla and several duplicates in Gentoo bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #21 from t dot artem at mailcity dot com 2007-11-04 13:42 --- > I would say let's close this as fixed. Do you mean that GCC 4.1 and 4.2 will never have this bug fixed and we have to wait till 4.3 is out? Besides, have you tested this bug on architectures other that Intel core2? Originally this bug affected plain i386 code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug regression/26290] New: [4.1 Regression]: some loop optimizations no longer run at -O2
In this simple testcase (file will be attached) 1) GCC 4.1 with -O2 produces code which runs two time slower than with -O3 thus some optimizations are missing at -O2 because GCC 4.0.2 -O2 works OK and produces results on par with -O3. 2) GCC 4.1 produces slightly slower code with -O3 than GCC 4.0.2 (with -O3). P.S. -fregmove was used as an extra compiler flag. -- Summary: [4.1 Regression]: some loop optimizations no longer run at -O2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t dot artem at mailcity dot com GCC build triplet: i686-pc-linux-gnu-gcc GCC host triplet: i686-pc-linux-gnu-gcc GCC target triplet: i686-pc-linux-gnu-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug regression/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
--- Comment #1 from t dot artem at mailcity dot com 2006-02-14 18:52 --- Created an attachment (id=10850) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10850&action=view) A testcase Here's a testcase. For those who couldn't understand the point: GCC 4.1.0 -O2 produces the code which runs two times slower than the code produced by GCC 4.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
-- t dot artem at mailcity dot com changed: What|Removed |Added Severity|minor |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #12 from t dot artem at mailcity dot com 2006-02-21 04:56 --- This bug may affect real applications performance so I believe it's worth being resolved for 4.1.0 release. What if one changes severity to critical though certanly this bug isn't critical? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
