[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71639 Frank Bergemann changed: What|Removed |Added CC||FBergemann at web dot de --- Comment #6 from Frank Bergemann --- Sorry, my fault! You can set this RESOLVED INVALID. It's about iterator invalidation because of capacity change. best regards, Frank
[Bug c++/61577] New: [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Bug ID: 61577 Summary: [4.9.0] can't compile on hp-ux v3 ia64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: FBergemann at web dot de Target: HP-UX v3 ia64 I cannot compile gcc-4.9.0 on a hp-ux B.11.31 (v3) ia64 machine. I used following component: ls -tlr total 40 drwxr-xr-x 18 frank os_int 8192 Jun 17 09:40 binutils-2.24 drwxr-xr-x 16 frank os_int 8192 Jun 17 15:31 gmp-6.0.0 drwxr-xr-x 10 frank os_int 8192 Jun 17 15:34 mpfr-3.1.2 drwxr-xr-x 7 frank os_int 8192 Jun 17 15:35 mpc-1.0.2 drwxr-xr-x 35 frank os_int 8192 Jun 21 09:31 gcc-4.9.0 +) binutis had been compiled separately first into a /gs/frank/hp-ux/gcc-4.9.0/ dir) +) gmp, mpfr and mpc source directories had been linked below gcc directory. +) $PATH had been set to select /usr/local/gcc-4.7.2 for compilation (compiler provided by HP) +) compilation is for 32bit +) ../configure --prefix=/gs/frank/hp-ux/gcc-4.9.0 --enable-languages=c,c++ --with-gnu-as --with-as=/gs/frank/hp-ux/gcc-4.9.0/bin/as --without-gnu-ld --disable-nls --disable-shared cat configure.out.fbe checking build system type... ia64-hp-hpux11.31 checking host system type... ia64-hp-hpux11.31 checking target system type... ia64-hp-hpux11.31 checking for a BSD-compatible install... /usr/local/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libcilkrts support... no checking for libitm support... no checking for libsanitizer support... no checking for libvtv support... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for gnatbind... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for version 0.10 of ISL... no checking for version 0.11 of ISL... no checking for version 0.12 of ISL... no *** This configuration is not supported in the following subdirectories: target-libcilkrts target-libitm target-libsanitizer target-libvtv gnattools target-libada target-libgfortran target-libgo target-libffi target-libbacktrace target-zlib target-libjava target-libobjc target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... no checking for ar... ar checking for as... as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for readelf... readelf checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... no checking for gccgo... no checking for ar... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ar checking for as... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/nm checking for objdump... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/objdump checking for ranlib... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ranlib checking for readelf... no checking for readelf... readelf checking for strip... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... pre-installed in /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin checking where to find the target as... pre-installed in /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin
[Bug c++/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #1 from Frank Bergemann FBergemann at web dot de --- when i use --with-gnu-ld -with-ld=/usr/local/gcc-4.7.2/bin/g++ i get following error: gmake[3]: Entering directory `/tmp/FBE/gcc-4.9.0/obj3/gcc' gmake[3]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3/gcc' Checking multilib configuration for libgcc... Configuring stage 1 in ia64-hp-hpux11.31/libgcc configure: loading cache ./config.cache checking build system type... ia64-hp-hpux11.31 checking host system type... ia64-hp-hpux11.31 checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/local/bin/install -c checking for gawk... gawk checking for ia64-hp-hpux11.31-ar... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ar checking for ia64-hp-hpux11.31-lipo... lipo checking for ia64-hp-hpux11.31-nm... /tmp/FBE/gcc-4.9.0/obj3/./gcc/nm checking for ia64-hp-hpux11.31-ranlib... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ranlib checking for ia64-hp-hpux11.31-strip... /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/strip checking whether ln -s works... yes checking for ia64-hp-hpux11.31-gcc... /tmp/FBE/gcc-4.9.0/obj3/./gcc/xgcc -B/tmp/FBE/gcc-4.9.0/obj3/./gcc/ -B/gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/bin/ -B/gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/lib/ -isystem /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/include -isystem /gs/frank/hp-ux/gcc-4.9.0/ia64-hp-hpux11.31/sys-include sendsig: useracc failed. 0xb200 0x005000 Pid 18125 was killed due to failure in writing the signal context - possible stack overflow. checking for suffix of object files... sendsig: useracc failed. 0xb200 0x005000 Pid 18130 was killed due to failure in writing the signal context - possible stack overflow. configure: error: in `/tmp/FBE/gcc-4.9.0/obj3/ia64-hp-hpux11.31/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/FBE/gcc-4.9.0/obj3' gmake: *** [all] Error 2
[Bug c++/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Frank Bergemann FBergemann at web dot de changed: What|Removed |Added Severity|blocker |major --- Comment #2 from Frank Bergemann FBergemann at web dot de --- Change importance. First problem, that was hit, is about the native 'ld'. Second problem could be stack size issue (however stack size used on hpux is larger than used on other reference systems). \Frank
[Bug c++/60687] [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 --- Comment #3 from Frank Bergemann FBergemann at web dot de --- Hi Yury, ok - thanks! I didn't know, that the default is that high (#1024 for c++11). So you can close it RESOLVED/WORKSFORME or INVALID. - many thanks! best regards, Frank
[Bug c++/60687] New: [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 Bug ID: 60687 Summary: [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: FBergemann at web dot de [g++ 4.8.0 on Red Hat Linux 6.2 or Ubuntu Linux 12.04.3] the g++ compiler is in an endless loop and has to be killed for compiling main.cpp (attached next). Then i get following error trace: /opt/gcc-4.8.0/bin/g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp g++: internal compiler error: Terminated (program cc1plus) 0x40cba1 execute ../../gcc/gcc.c:2822 0x40cee4 do_spec_1 ../../gcc/gcc.c:4614 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40daff do_spec_1 ../../gcc/gcc.c:5373 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make: *** [main.o] Error 4
[Bug c++/60687] [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 --- Comment #1 from Frank Bergemann FBergemann at web dot de --- Created attachment 32466 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32466action=edit test program
[Bug c++/57416] New: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 Bug ID: 57416 Summary: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575 Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: FBergemann at web dot de Created attachment 30193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30193action=edit test program main.cpp compiled in eclipse with -std=c++11 while experimenting with http://www.drdobbs.com/cpp/access-data-items-in-ancestor-stack-fram/240155450 i got this error here: Build of configuration Debug for project RetainRecall make all Building file: ../main.cpp Invoking: GCC C++ Compiler /opt/gcc-4.8.0/bin/g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp ../main.cpp: In constructor ‘constexpr func1(PARENTDATA) [with PARENTDATA = Nothing]::Data::Data()’: ../main.cpp:43:9: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575 struct Data ^ 0x655603 gimple_expand_cfg ../../gcc/cfgexpand.c:4575 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make: *** [main.o] Error 1 Build Finished
[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 --- Comment #2 from Frank Bergemann FBergemann at web dot de --- Created attachment 30194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30194action=edit fixed version of test program - compilation works now Hi Daniel, thanks for the hint! - i was not aware of this rule. Attached a new version of test program, which doesn't have this problem anymore. best regards, Frank
[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 Frank Bergemann FBergemann at web dot de changed: What|Removed |Added Attachment #30194|0 |1 is obsolete|| --- Comment #3 from Frank Bergemann FBergemann at web dot de --- Created attachment 30195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30195action=edit fixed version of test program - compilation works now missed to fix another location of invalid code - sorry \Frank
[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 --- Comment #6 from Frank Bergemann FBergemann at web dot de --- the error depends on optimization level. -O0 has the problem -O1, -02, -03 do not have the problem. For those i get - even for the original buggy code: make all Building file: ../main.cpp Invoking: GCC C++ Compiler /opt/gcc-4.8.0/bin/g++ -O1 -g3 -Wall -c -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp ../main.cpp: In function ‘void func3(PARENTDATA) [with PARENTDATA = func2(PARENTDATA) [with PARENTDATA = func1(PARENTDATA) [with PARENTDATA = Nothing]::Data]::Data]’: ../main.cpp:23:47: warning: ‘p_parent_data’ may be used uninitialized in this function [-Wmaybe-uninitialized] std::cout parent_data.parent_data.x = data.parent_data.parent_data.x std::endl; ^ ../main.cpp: In function ‘void func2(PARENTDATA) [with PARENTDATA = func1(PARENTDATA) [with PARENTDATA = Nothing]::Data]’: ../main.cpp:29:9: warning: ‘p_parent_data’ is used uninitialized in this function [-Wuninitialized] Finished building: ../main.cpp Building target: RetainRecallOld Invoking: GCC C++ Linker /opt/gcc-4.8.0/bin/g++ -o RetainRecallOld ./main.o struct Data ^ ../main.cpp: In function ‘void func1(PARENTDATA) [with PARENTDATA = Nothing]’: ../main.cpp:43:9: warning: ‘p_parent_data’ is used uninitialized in this function [-Wuninitialized] struct Data ^ Finished building target: RetainRecallOld Build Finished
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #11 from FBergemann at web dot de 2010-01-20 08:39 --- Hi Paolo, here's the response from HP: I kindly would like to ask you for confirmation of the problem. Because i want to exclude that the problem is just due to our system set-up here. I would highly appreciate if you could try to re-produce the problem (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791) and give us positive or negative confirmation. I ran the test case from the GCC bug report using GCC 3.4.5 and Boost 1.33.1 and was able to reproduce the problem on my system. For decision making about new gcc compiler version to use, i would like to ask you for a proposal - especially related to performance issues. Because there are difference gcc version packages available from your download sites. Generally, I recommend using the most recent GCC version available. If you confirm the problem, then it might also be helpful to add the information to your web-site, porting guidelines, etc. - for all your customers (they might hit the same problem) Or ask gnu to fix it. The FSF is not going to fix anything on the 3.4.* branch, this branch is considered 'dead' and is no longer being maintained. [...] [@cup.hp.com So could you pls. set it to WONTFIX - because WORKSFORME means it works - but it doesn't. Just for other people facing the same problem again. We check for new compiler version to use now. Thanks for your help! cheers, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #13 from FBergemann at web dot de 2010-01-20 15:00 --- Hi paolo.carl...@oracle.com, the funny thing about your last comment is, that the company i am working for is selling quite successfully large systems with adjunct big oracle database cluster systems to Tier-1 operators. Until now holding on a completely obsolete compiler nobody is interested in which fulfilled our needs for stability and performance was not a bad idea :-) regards, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #9 from FBergemann at web dot de 2010-01-19 09:25 --- change Reported against to 3.4.6. Because 3.4.6 is the last version of the 3.4.x series. I tested with that as well, but it fails, too. And i would have withdrawn this issue, if it would have worked for 3.4.6. This means, that gcc-3.4.x has a deficit for hp-ux B11.31 ia64 and should not be used for that architecture - unless some fellows at HP will make negative confirmation and proof that's it's e.g. due to the set-up of my machine. I'll ask HP for verification - and likely switch to a newer gcc :-) rgds, Frank -- FBergemann at web dot de changed: What|Removed |Added Version|3.4.4 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #10 from FBergemann at web dot de 2010-01-19 10:06 --- if i compile the sample on hp-ux ia64 for 32 bits, it's generating a coredump: (gdb) r Starting program: /nfs/uh01/frank/TESTX/sample test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0' Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3. boost::spirit::grammarbasic_xml_grammarchar,boost::spirit::parser_contextboost::spirit::nil_t ::grammar (this=0x40025cf0) at sp_counted_base_gcc_ia64.hpp:38 38 r(pw)); seems to be related to alignment(?!) rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] New: boost[1.33.1]::spirit depends on optimization level
Hello,
i posted a problem against boost::serialization.
(http://article.gmane.org/gmane.comp.lib.boost.user/54935).
But now i could track it down to boost::spirit.
I have extracted boost::serialization stuff , which is dealing with boost
spirit, in a mini demo program
(will attach tar file next).
It accepts XML input if compiled with -O0 or -O1 and returns #1 (hit) for it:
|hpux03 407 make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 408 ./sample
test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0'
parse_start_tag('pDeleteHlrSubscriberIn class_id=0 tracking_level=0
version=0') returned 1
But it fails (return #0 no hit), if i use -O2 or -O3:
|hpux03 411 make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 412 ./sample
test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0'
parse_start_tag('pDeleteHlrSubscriberIn class_id=0 tracking_level=0
version=0') returned 0
Is it a bug of gcc-3.4.4? (for HP-UX B11.31 ia64?)
Or boost::spirit using experimental C++ feature (for level of gcc-3.4.4)?
- many thanks!
Frank Bergemann
--
Summary: boost[1.33.1]::spirit depends on optimization level
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: FBergemann at web dot de
GCC build triplet: ia64 hp-ux B11.31
GCC host triplet: ia64 hp-ux B11.31
GCC target triplet: ia64 hp-ux B11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #1 from FBergemann at web dot de 2010-01-18 12:18 --- Created an attachment (id=19646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19646action=view) tar file with mini program sources Makefile Pls change the optimization level in Makefile to see the differences. To successfully compile it requires -I for the boost include files. Remember i uses boost 1.33.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #3 from FBergemann at web dot de 2010-01-18 12:55 --- Hi Paolo, i tested again with 1) gcc-4.1.2 package delivered from HP (installed at /opt/hp-gcc-4.1.2/) - it works (no such problem) But there were some warning for compilation /var/tmp//ccgkYSFL.s: Assembler messages: /var/tmp//ccgkYSFL.s:1057: Warning: Use of 'add' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 44 /var/tmp//ccgkYSFL.s:1057: Warning: Only the first path encountering the conflict is reported /var/tmp//ccgkYSFL.s:1056: Warning: This is the location of the conflicting usage 2) gcc-4.3.1 package delivered from HP (installed at /opt/hp-gcc-4.3.1/) - it works (no such problem, also no warnings during compilation) 3) self-compiled /usr/local/gcc-4.3.3/ - it works (no such problem) To make it compile for gcc versions 3.4.4, i just needed to fix the fbe_xml_grammar.hpp to drop extra qualification 'basic_xml_grammarCharType::' on member 'parse_start_tag' respectively 'parse_end_tag' and 'parse_string'. shall i attach again the modified source.tar.gz for this? - thanks! rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #5 from FBergemann at web dot de 2010-01-18 13:31 --- Hi Paolo, well switching to more recent version might be a solution - but unfortunately not that easy to implement for me. It's a big project i am working in. Switching the compiler means invoking our release management to re-create the application release. For this they need to re-create all binary components it depends on, before. Then we have to re-start entire system tests, rollout to customers, etc, ... Before i consider this i need to know where the problem is actually. Is it possible to get a confirmation, that gcc-3.4.4 has some deficit(s) on hp-ux ia64 B11.31? Because it might affect some or all our products on HP-UX. Is there a deficit list for gcc-3.4.4 for HP-UX ia64 B11.31? I tried to look it up on this bug system - but couldn't find such kind of summary. We are also involving HP for this now. And a request to boost.org is also pending. One important thing: The reason, why we are stuck to 3.4.4 here is, that in the past this was a well-optimized compiler (performance). We have been told that newer versions are slower. Now for gcc.4.3.x i am not sure, if this argument is still valid?! Can you gimme some help in that - about performance impacts from switching from 3.4.4 to 4.3.x? - many thanks! best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #7 from FBergemann at web dot de 2010-01-18 14:16 --- Hi Paolo, shouldn't it be WONTFIX then? (as it is against 3.4.4) best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
