https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246
--- Comment #4 from Mike Jarvis ---
Created attachment 37984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37984&action=edit
An alternate source that uses a custom Complex class
OK, here is a version that rolls its own Complex class, rath
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael at jarvis dot net
Target Milestone: ---
Created attachment 37980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37980&action=edit
Source code
The attached code is extracted from a larger code base t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246
--- Comment #1 from Mike Jarvis ---
Created attachment 37981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37981&action=edit
Preprocessed file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #25 from Mike Jarvis ---
The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2. I no longer
have access to a 10.6 machine, so I cannot confirm whether it is fixed with 4.8
on that system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
Mike Jarvis changed:
What|Removed |Added
Severity|normal |minor
--- Comment #10 from Mike Jarvis 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #9 from Mike Jarvis 2011-06-10 21:47:37
UTC ---
That worked. So I guess g++ is exceeding the stack limit and crashing, not the
heap memory.
$ ulimit -aH
core file size (blocks, -c) 0
data seg size (kbytes, -d) unl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #8 from Mike Jarvis 2011-06-10 21:26:59
UTC ---
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #6 from Mike Jarvis 2011-06-10 21:04:59
UTC ---
I figured out how to install a 64 bit version of g++ on my machine, and I also
booted up the machine with 6 and 4 held down to get the 64 bit kernel.
And this didn't help. I'm still
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #4 from Mike Jarvis 2011-06-10 14:02:45
UTC ---
That's a bit odd. The final function in the .ii file consists of two function
calls. If I delete either one of these, the compile succeeds and only uses
about 1100M (RSIZE in top).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #1 from Mike Jarvis 2011-06-10 00:54:35
UTC ---
I should add that g++ version 4.4.4 also fails to work with this code. It
gives the same "Internal error: Segmentation fault" that 4.5.2 gave.
But g++ 4.0.1 and 4.2.1 do work.
Well,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
Summary: Internal error: Segmentation fault (program cc1plus)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
I'm not sure whether to call this a new bug or not, because the error is very
similar to the existing bug 42159. However, the system I am on does not crash
for the code listed in that bug report. Also, the comments for that bug seem
to be indicating that the bug is specific to Snow Leopard, while
--- Comment #18 from michael at jarvis dot net 2010-06-06 19:32 ---
I can confirm the bug on my system (MacOS 10.6.3, Intel Core i7) with g++
4.4.2, 4.4.3 and 4.4.4.
However, I have discovered a workaround. Linking with -lpthread makes the
problem go away, both for this simple test
--- Comment #3 from michael at jarvis dot net 2009-12-24 05:13 ---
Created an attachment (id=19385)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19385&action=view)
full g++ -v output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
--- Comment #2 from michael at jarvis dot net 2009-12-24 05:12 ---
Created an attachment (id=19384)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19384&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
--- Comment #1 from michael at jarvis dot net 2009-12-24 05:12 ---
Created an attachment (id=19383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19383&action=view)
source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
n: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at jarvis dot net
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target
--- Comment #2 from michael at jarvis dot net 2008-07-06 11:40 ---
(From update of attachment 15863)
g++ -v outputs:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.2
--mandir=/sw/share/man --infodir=/sw/share
--- Comment #1 from michael at jarvis dot net 2008-07-06 11:31 ---
Created an attachment (id=15863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15863&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36742
The following code produces correct output with g++ -O, but wrong output with
g++ -O2:
The basic calculation should be just a product of two complex numbers, each
equal to (1,1), so the output should be (and is with g++ -O):
a = (0,2)
However, on my system, the output with the -O2 flag is:
a = (
20 matches
Mail list logo
