https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #56 from Sergei Steshenko ---
"-O2 ... and 820MB peak memory use" vs "-O3 ... and 700MB peak memory use" -
according to my common sense -O3 is stronger than -02 optimization, and one
should expect greater memory use.
So, can the abov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #37 from Sergei Steshenko 2013-03-07
21:47:52 UTC ---
(In reply to comment #35)
> (In reply to comment #34)
> > Memory consumption appears to be the same as with -O2.
>
> Can you measure the peak memory with time?
>
> /u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #34 from Sergei Steshenko 2013-03-07
17:13:42 UTC ---
Somehow, with -O3 LLVM clang works a little bit faster than with -O2 - 54
minutes instead of 58 minutes, though this might be a random variation:
"
sergei@amdam2:~/gcc_bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #32 from Sergei Steshenko 2013-03-07
10:13:40 UTC ---
(In reply to comment #26)
> (In reply to comment #23)
> > FYI, the original file (
> > http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 )
> > can be compiled with 'clan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #23 from Sergei Steshenko 2013-03-06
16:49:51 UTC ---
FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 )
can be compiled with 'clang', albeit slowly:
"
sergei@amdam2:~/gcc_bug> time ~/AFSWD/instal
--- Comment #23 from sergstesh at yahoo dot com 2010-05-23 04:49 ---
Just wondering after so many adjustments - is the bug going to be fixed ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
--- Comment #2 from sergstesh at yahoo dot com 2009-05-12 15:43 ---
No, the documentation explicitly says
( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):
"
5.3 Labels as Values
...
To use these values, you need to be able to jump to one. This is done wit
248 in
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf
, they don't mention optimizations (or did I miss it ?).
The problem also exists with gcc-3.4.6.
--
Summary: -O2 and higher causes wrong label address calculation
Product: gcc
Version: 4.3.3
Status: U
--- Comment #7 from sergstesh at yahoo dot com 2009-04-11 17:01 ---
Regarding "Could you attach the build log?" - isn't it already attached
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17620
?
The file is gzipped because in plain form it's bigger than 1MB.
--
--- Comment #6 from sergstesh at yahoo dot com 2009-04-11 16:55 ---
Sorry, not
"Also, there were 'binutils' elements in the paths."
, but
Also, there were no 'binutils' elements in the paths.
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
--- Comment #5 from sergstesh at yahoo dot com 2009-04-11 16:54 ---
stdio.h at system level is where it originally was:
/usr/include/stdio.h
/usr/include/c++/4.2.1/tr1/stdio.h
/usr/include/bits/stdio.h
.
Regarding 'gcc' configure options - do you mean normal native 'g
--- Comment #3 from sergstesh at yahoo dot com 2009-04-11 14:00 ---
Created an attachment (id=17620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17620&action=view)
'make' screen output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
--- Comment #2 from sergstesh at yahoo dot com 2009-04-11 13:57 ---
Created an attachment (id=17619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17619&action=view)
'configure' screen output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
--- Comment #1 from sergstesh at yahoo dot com 2009-04-11 13:55 ---
Created an attachment (id=17618)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17618&action=view)
autogenerated script used to run 'configure'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: i686-pc-linux-gnu
G
--- Comment #16 from sergstesh at yahoo dot com 2009-03-03 14:15 ---
(In reply to comment #15)
> Subject: Re: Segmentation fault with -O1, out of memory
> with -O2
>
> On Tue, 3 Mar 2009, sergstesh at yahoo dot com wrote:
>
> > --- Comment #14 from sergs
--- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 ---
'spiral' has produced another testcase which segfaults with -O2 - the original
testcase segfaults with -O1.
The testcase, though has half the points if terms of FFT, is big as a file:
-rw-r--r-- 1 se
--- Comment #11 from sergstesh at yahoo dot com 2009-03-01 03:54 ---
(In reply to comment #5)
> Try -fno-move-loop-invariants. This is probably a killer on
> alias-improvements
> branch as well.
>
Still segfault:
"
gap_TlnLv4.c: In function âRDFT_49152_1â:
ga
--- Comment #10 from sergstesh at yahoo dot com 2009-03-01 03:09 ---
I am not sure whether it's clear - the smaller 'gap_bzAJWH.c.gz' file can be
found as
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378&action=view
attachment.
--
http://gcc.gnu.org/bugzi
--- Comment #9 from sergstesh at yahoo dot com 2009-03-01 03:06 ---
(In reply to comment #6)
> As this seems to be autogenerated from
>
> ! The SPL Program: (compose (sparse (coords (...12288 x 2 ...))(values (...1 x
> 12288 ...)))(compose (conjugate (..)(
--- Comment #8 from sergstesh at yahoo dot com 2009-03-01 03:03 ---
Created an attachment (id=17378)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378&action=view)
a smaller file with hopefully the same pattern
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #4 from sergstesh at yahoo dot com 2009-02-28 17:23 ---
FWIW, 'gcc-3.4.6', when run as
/mnt/sdb8/sergei/AFSWD_debug/install/gcc-3.4.6/binsh/gcc -O1
-fomit-frame-pointer -malign-double -fstrict-aliasing -c
/tmp/spiral-sergei/gap_TlnLv4.c -o gap_TlnLv4.o
, fails
--- Comment #3 from sergstesh at yahoo dot com 2009-02-28 15:34 ---
There is no failure with -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #2 from sergstesh at yahoo dot com 2009-02-28 15:32 ---
My OS:
Linux amdam2 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 i686 athlon
i386 GNU/Linux
- SUSE 10.3 in simple English; 'gcc' is self-built 'gcc-4.3.3'.
--
http://gcc.gnu.org/bugz
--- Comment #1 from sergstesh at yahoo dot com 2009-02-28 15:29 ---
Created an attachment (id=17377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377&action=view)
source file causing the failure
The source is not preprocessed, it has only standard
#include
th -O1, out of memory with -O2
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build tr
--- Comment #1 from sergstesh at yahoo dot com 2009-01-25 06:33 ---
Created an attachment (id=17179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17179&action=view)
screen output of 'make -k check'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38963
n: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet
--- Comment #17 from sergstesh at yahoo dot com 2009-01-08 22:26 ---
(In reply to comment #16)
> (In reply to comment #15)
> > This is fixed in 4.4 by IRA:
> >
> > gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
> > -fno-ira
&g
--- Comment #15 from sergstesh at yahoo dot com 2009-01-08 22:18 ---
(In reply to comment #14)
> This is fixed in 4.4 by IRA:
>
> gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
> -fno-ira
> gcc_bug.c: In function main:
> gcc_bug.c:230
--- Comment #8 from sergstesh at yahoo dot com 2008-12-30 00:08 ---
(In reply to comment #7)
> (In reply to comment #6)
> > My primary concern is segmentation fault, not the cases when 'gcc' can't
> > allocate enough memory and reports the problem clear
--- Comment #6 from sergstesh at yahoo dot com 2008-12-30 00:00 ---
(In reply to comment #5)
> The function is simply too big and we likely use most of the memory computing
> and storing the const reals. A case for closer investigation.
>
(In reply to comment #5)
> The
--- Comment #4 from sergstesh at yahoo dot com 2008-12-29 22:45 ---
Just to make sure - my OS is 32 bits SUSE-10.3, though the CPU is 64 bits
capable.
--
sergstesh at yahoo dot com changed:
What|Removed |Added
--- Comment #3 from sergstesh at yahoo dot com 2008-12-29 21:57 ---
No problem occurs with -O0; with -O2, -O3 'gcc' also exits gracefully:
cc1: out of memory allocating 4283978752 bytes after a total of 228749312 bytes
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
--- Comment #2 from sergstesh at yahoo dot com 2008-12-29 21:53 ---
The bug is data-dependent. If inside the 'for' loop I replace all the
coefficients with 1.0, the failure is graceful:
cc1: out of memory allocating 4054207356 bytes after a total of 105562112 bytes
.
--- Comment #1 from sergstesh at yahoo dot com 2008-12-29 21:50 ---
Created an attachment (id=17005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17005&action=view)
'gcc_bug.i.gz' file produced by 'gcc' and 'gzip' from the input 'gcc_bug.
mmand.
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #6 from sergstesh at yahoo dot com 2008-03-26 20:58 ---
(In reply to comment #5)
> As mentioned, use -fcx-limited-range.
>
Can't you add just _one_ command line switch: -old_behavior ?
Or -gcc_4_2_3_behavior ?
For example, I need FFTW3 with "float"
--- Comment #4 from sergstesh at yahoo dot com 2008-03-26 20:44 ---
(In reply to comment #3)
> This was an intentional change for correctness. 4.3 uses the library
> implementation to handle the case of NaNs correctly. Use -fcx-limited-range
> if you want back the pe
--- Comment #2 from sergstesh at yahoo dot com 2008-03-26 19:40 ---
My system:
Linux amdam2 2.6.18.8-0.9-default #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686
athlon i386 GNU/Linux
- SUSE 10.2, the CPU is: "AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping 02".
--- Comment #1 from sergstesh at yahoo dot com 2008-03-26 19:23 ---
Created an attachment (id=15383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15383&action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo 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=35709
--- Comment #23 from sergstesh at yahoo dot com 2008-01-21 05:07 ---
It's too bad the bug is closed just as a duplicate of another bug.
The main points of this bug are:
1) the code triggering the bug uses undefined in "C" standards language
features - behavior in
--- Comment #21 from sergstesh at yahoo dot com 2008-01-20 22:30 ---
Now that the flags are in this order: -Wall -Wstrict-overflow=5 :
a) the warnings during compilation:
"
[EMAIL
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep warn make.log
l
--- Comment #19 from sergstesh at yahoo dot com 2008-01-18 23:33 ---
Regarding "BTW, is your makefile adding -Wstrict-overflow after or before -Wall
-Wextra?".
Here is how the first action line in 'make.log' looks:
"
23 if /bin/sh ../../libtool --tag=C
--- Comment #16 from sergstesh at yahoo dot com 2008-01-18 14:19 ---
A general though regarding optimization - do _not_ optimize code producing
warnings, and notify end user, so there will be much more incentive to write
clean code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #15 from sergstesh at yahoo dot com 2008-01-18 14:08 ---
With CFLAGS='-O2 -Wstrict-overflow=5' still there is no warnings in
'make_check.log':
"
[EMAIL
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep -i warn mak
--- Comment #12 from sergstesh at yahoo dot com 2008-01-18 03:20 ---
Regarding
"
About the dependency on optimization level, signed integer overflow is
undefined in C standard so its not a good idea to depend on it. What GCC does
is exploiting this fact for optimizations which is
--- Comment #10 from sergstesh at yahoo dot com 2008-01-18 03:05 ---
Ismail, the problem, as I see it, is not the failure itself, but rather
dependency on optimization level.
My point is that if the code is buggy WRT signedness, it should be the same
way buggy for any level of
--- Comment #8 from sergstesh at yahoo dot com 2008-01-18 01:52 ---
With CFLAGS='-O2 -Wstrict-overflow' still no warnings in 'make_check.log' and
"
[EMAIL
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep -i warn make.log
--- Comment #6 from sergstesh at yahoo dot com 2008-01-18 01:43 ---
I've tried CFLAGS='-O2 -fwrapv -Wstrict-overflow' and I see no warnings at all
in 'make_check.log' file - I tried "grep -i warn make_check.log".
OTOH:
"
[EMAIL
PROTECTED]:/mnt/
--- Comment #4 from sergstesh at yahoo dot com 2008-01-18 01:33 ---
"-O2 -fwrapv" fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
--- Comment #3 from sergstesh at yahoo dot com 2008-01-18 01:28 ---
With "-O2 -fno-strict-aliasing" the failure is still there, I'll check with
"-O2 -fwrapv" right away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
--- Comment #1 from sergstesh at yahoo dot com 2008-01-18 00:40 ---
The tarball: http://www.filelime.com/upload/files/gcc4.2.x-O2_bug.tar.gz .
--
sergstesh at yahoo dot com changed:
What|Removed |Added
ation, OK with -O1 one
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC host triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
--- Comment #17 from sergstesh at yahoo dot com 2006-11-19 02:20 ---
Regarding
"
> Is it that gcc-4.1.1 falsely aligns the memory location in question ?
Well it can be 8byte aligned and accidently also 16byte aligned (which does
happen every once in a while).
"
The or
--- Comment #15 from sergstesh at yahoo dot com 2006-11-19 01:59 ---
Is the alignment requirement always applicable in all the cases, or just
for gcc-3.4.6 ?
Remember, in this case gcc-4.1.1 produces code which doesn't segfault.
Is it that gcc-4.1.1 optimizes out the failing line
--- Comment #5 from sergstesh at yahoo dot com 2006-11-18 15:17 ---
IIRC, misaligned data should cause performance penalty, not segmentation fault.
Look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , at the case when
there is no segfault:
"
when the code runs fine
--- Comment #3 from sergstesh at yahoo dot com 2006-11-18 06:18 ---
Created an attachment (id=12639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12639&action=view)
.i source file not causing segfault
This is .i source file with line #157..167 commented out, and ther
--- Comment #2 from sergstesh at yahoo dot com 2006-11-18 06:15 ---
Created an attachment (id=12638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12638&action=view)
.i source causing segfault
This is the .i file which causes segfault.
Line #157..167 are not commen
--- Comment #1 from sergstesh at yahoo dot com 2006-11-18 06:10 ---
Created an attachment (id=12637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12637&action=view)
the "C" file causing the failure
If I run this file, it fails with:
"
checkpoint 1
&si
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep
26 12:41
GCC host triplet: Linux com
--- Comment #13 from sergstesh at yahoo dot com 2006-11-17 02:23 ---
(In reply to comment #11)
> I'm only a bug master and don't do any work on the compiler anyway, so my
> say isn't worth much, but here's my take:
>
> You propose that you can give us
--- Comment #10 from sergstesh at yahoo dot com 2006-11-17 02:03 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Please see
> >
>
> Can you try the patch mentioned in:
> http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html
>
> (I am about
--- Comment #8 from sergstesh at yahoo dot com 2006-11-17 01:27 ---
Please see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874
- another proof that gcc-3.4.6 generates better SSE code than gcc-4.1.1, and
the
proof uses only widely available and well known GPL'ed code.
--
--
Summary: gcc-4.1.1 generates consistently worse performming SSE
code than gcc-3.4.6
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assigned
--- Comment #7 from sergstesh at yahoo dot com 2006-11-14 02:54 ---
(In reply to comment #6)
> (In reply to comment #5)
> > We can make a deal: I obfuscate and publish the code, you guys fix the
> > bug preserving, if possible, performance.
> >
> > The code
--- Comment #5 from sergstesh at yahoo dot com 2006-11-14 01:36 ---
(In reply to comment #4)
> (In reply to comment #3)
> > I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6
> > is
> > the best so far. Sorry, I cant' post the code
--- Comment #3 from sergstesh at yahoo dot com 2006-11-14 01:04 ---
(In reply to comment #2)
> You should note that 3.4.x is no longer being maintained so this bug will most
> likely be closed as fixed as you already mention it works in 4.1.1.
>
That's too bad.
I am dev
--- Comment #1 from sergstesh at yahoo dot com 2006-11-13 16:40 ---
Created an attachment (id=12606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12606&action=view)
source code which causes the segfault under gcc-3.4.6 and runs fine under
gcc-4.1.1
The file is the resul
gcc-4.1.1
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: Li
--- Comment #4 from sergstesh at yahoo dot com 2006-11-09 23:01 ---
Thanks for your reply.
Regarding
"
FAIL: g++.old-deja/g++.law/weak.C (test for excess errors)
Unknown and you should look into g++.log.
"
- you probably meant gcc/testsuite/g++/g++.log.sent file.
If it&
--- Comment #2 from sergstesh at yahoo dot com 2006-11-09 22:30 ---
After using 'make -k check' I see much more failures that reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
, i.e. in my environment gcc-4.1.1 test suite produces much more failures
than gcc-
--- Comment #8 from sergstesh at yahoo dot com 2006-11-09 13:41 ---
I looked into source code of 'test_summary' script and it indeed calls
the 'Mail' program, the one with capital 'M'.
I have never heard of it, I am familiar with 'mail' with smal
--- Comment #7 from sergstesh at yahoo dot com 2006-11-08 23:29 ---
OK, being in
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6
directory, which is my 'obj' directory, I tried to run the 'test_summary'
mentioned at the bottom of http://gcc.gnu.org/instal
--- Comment #4 from sergstesh at yahoo dot com 2006-11-08 22:43 ---
I read the document: http://gcc.gnu.org/install/test.html, but it doesn't
answer my questions.
If you need test results reported through the suggested
srcdir/contrib/test_summary -p your_commentar
--- Comment #2 from sergstesh at yahoo dot com 2006-11-08 21:44 ---
I do not understand you comment.
That is, from 'make' manpage:
"
-k Continue as much as possible after an error. While the target
that failed, and those that depend on it, can
ers.
Please let me know whther you need any additional info.
--
Summary: 'make check' for gcc-4.1.1 fails
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Ass
dc++-v3] Error 2
".
The majority of tests pass.
Please let me know whether you need additional info.
--
Summary: 'make check' for gcc-3.4.6 fails
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
79 matches
Mail list logo
