So the private (localTodoStack) clause really doesn't have the desired effect (a private variable will be constructed, but nothing will ever use it) - localTodoStack in quick_sort is still a shared The graph-tool build error is related to boost, which I installed using macports (version 1.47) . Index Nav: [DateIndex] [SubjectIndex] [AuthorIndex] [ThreadIndex] Message Nav: [DatePrev][DateNext] [ThreadPrev][ThreadNext] Other format: [Raw text] [Bug c++/66859] New: internal compiler error: in lower_stmt From: "t at sharklasers dot com"
Preprocessed source stored into /tmp/ccGTvUkN.out file, please attach this to your bugreport. Thanks. It is Fedora's policy to close all bug reports from releases that are no longer maintained. I > could install the normal version of gcc4.6 which is the latest in > macports. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36237
After installing ("make install"), the following error occurred when attempting to import graph-tool:>>>>>>> In : import graph_tool---------------------------------------------------------------------------ImportError Maybe they can fix the scipy portfile to allow an universal build. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. The error vanishes if the definition of TestClass::TestClass() is moved into the declaration of TestClass.
Format For Printing -XML -Clone This Bug -Top of page First Last Prev Next This bug is not in your last search results. I too have very little experience with Mac's multiple architecture concept. (This would have been done days ago in Linux. Bug40948 - ICE in lower_stmt, at gimple-low.c:408 Summary: ICE in lower_stmt, at gimple-low.c:408 Status: RESOLVED FIXED Alias: None Product: gcc Classification: Unclassified Component: c++ (show other bugs) Version: 4.4.1 Importance: P3 argh!) Sadly, the plot thickens.
comment:4 Changed 12 months ago by [email protected]… Status changed from new to closed Resolution set to wontfix No response, and, really, does this matter any longer? After including the two -arch flags and running configure, the compiler gets tripped up immediately. So I doubt my problems have to do with Enthought. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40948 Maybe they can fix the scipy portfile to allow an universal build.
sigh... Summary: internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(lo... See
If you want it to be private, you should pass it by reference to quick_sort, or use threadprivate var, or perhaps the easiest just use an automatic variable in quick_sort function. https://bugzilla.redhat.com/show_bug.cgi?id=452972 I have very little experience with building stuff with multiple architectures with apple's GCC, but according to the documentation you should pass something like "-arch i386 -arch x86_64" to the compiler Just one of the very many MacOS annoying peculiarities. net [Download message RAW] This code is giving me an ICE: #include
Comment 1 Albert Sidelnik 2008-01-11 19:34:13 EST Created attachment 291441 [details] Dump of output Comment 2 Albert Sidelnik 2008-01-11 19:36:19 EST Created attachment 291443 [details] Testcase Comment 3 Bug Zapper 2008-11-26 useful reference I try to compile with: $ g++ openmp_gsl_rng.cpp -I/mn/anatu/cma-u3/tmac/usr/include -L/mn/anatu/cma-u3/tmac/usr/lib -lgsl -lgslcblas -fopenmp Actual Results: I get the following error message: openmp_gsl_rng.cpp: In function 'int main()': openmp_gsl_rng.cpp:0: internal compiler error: in OpenMP and GSL RNG Status: CLOSED ERRATA Aliases: None Product: Red Hat Enterprise Linux 5 Classification: Red Hat Component: gcc (Show other bugs) Sub Component: --- Version: 5.2 Hardware: i686 Linux Of course, FSF's "stock" gcc from macports compiles it as well, but for some reason things which are compiled with it do not work well with the rest of the system
This probably came about due to MacPorts 2.2 which now uses gcc-4.2 as the default compiler on Leopard instead of gcc-4.0. Did find: > /usr/local/lib/python2.7/site-packages/graph_tool/libgraph_tool_core.so: mach-o, but wrong architecture > >>>>>>>> > > These architecture issues on Mac are mystifying to me. I'd have to investigate further. my review here Format For Printing -XML -Clone This Bug -Top of page Home | New | Browse | Search | [?] | Reports | Help | NewAccount | Log In Remember [x] |
Comment 7 Jakub Jelinek 2009-08-03 14:57:56 UTC Seems this is cleanup of the finish_compound_literal returned TARGET_EXPR vs. This report is therefore being closed with a resolution of ERRATA. From the ./configure command you sent in the first email, it did not seem you passed this.
From the ./configure command you sent in the first email, it did not seem you passed this. NAML View this message in context: Re: boost errors building on Mac OSX Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com. _______________________________________________ graph-tool mailing Xcode 3.2.6 has gcc-4.2 build 5666 dot 3 so we don't need to blacklist that, but I don't know where between 5578 and 5666.3 the problem was fixed. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products.
But I notice you are using llvm-g++. Maybe you guys can test with a standard GSL/Blitz++ if that comes precompiled with RHEL5.2. Comment 11 errata-xmlrpc 2009-01-20 16:25:08 EST An advisory has been issued which should help the problem described in this bug report. get redirected here Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8.
Bug36237 - internal compiler error: in lower_stmt, at gimple-low.c:282 erase 'private(localTodoStack)' it compiles successfully. The issues occur with graph-tool-2.2.15 (though I've also had issues with the lastest code from github). How can > something be built for the wrong architecture if I just compiled it > for that architecture? Maybe you should try the regular (non-llvm) g++? > I noticed that gcc 4.4 is required for compilation.