[Bug analyzer/97240] New: Analyzer runs out of memory building C++ source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97240 Bug ID: 97240 Summary: Analyzer runs out of memory building C++ source Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Target Milestone: --- Created attachment 49285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49285&action=edit Preprocessed source Compiling source with -fanalyzer incommand line causes gcc-10.2.0 run out of memory. g++ -c -v -std=c++17 -fanalyzer FastMathTest.ii Using built-in specs. COLLECT_GCC=g++ Kohde: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Säiemalli: posix Supported LTO compression algorithms: zlib zstd gcc-versio 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-std=c++17' '-fanalyzer' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -fpreprocessed FastMathTest.ii -quiet -dumpbase FastMathTest.ii -mtune=generic -march=x86-64 -auxbase FastMathTest -std=c++17 -version -fanalyzer -o /tmp/ccZO5KJm.s GNU C++17 (GCC) versio 10.2.0 (x86_64-pc-linux-gnu) käännetty GNU C:n versiolla 10.2.0, GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++17 (GCC) versio 10.2.0 (x86_64-pc-linux-gnu) käännetty GNU C:n versiolla 10.2.0, GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2affcd71b0797e2421aae734ab600c81 Killed compile when memory use exceeded 70 GB.
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #6 from Andris Pavenis --- Failed to reproduce - gcc-6.3.0 - Windows 10 32 bit VM (VirtualBox) under Fedora 25 x86_64 - DJGPP libc trunk version (should also work with DJGPP v2.05) Alignments supported by GCC (up to 128 seems) to work OK for me.
[Bug preprocessor/71681] header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 --- Comment #2 from Andris Pavenis --- Created attachment 39551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39551&action=edit Test script to reproduce problem
[Bug preprocessor/71681] header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 --- Comment #1 from Andris Pavenis --- Created attachment 38781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38781&action=edit Fix for problem
[Bug preprocessor/71681] New: header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 Bug ID: 71681 Summary: header.gcc file lookup is broken for -remap Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Target Milestone: --- Looking up header.gcc files in sub-directories (for example in case of '#include ') is broken as directory separator is missing in generated file names. Added simple debugging output to static method remap_filename() in libcpp/files.c. Some examples illustrating missing directory separator from debug output are given below. remap_filename() finds header file in top directories of include search path but not in subdirectories in part of cases (one is getting new_dir='/usr/includesys/' where name should have been './usr/include/sys/') Test example foo.c: #include "foo/bar/baz.h" #include Used gcc version 7.0.0-20160628. Problem present also in several earlier GCC versions. Problem actually detected for DJGPP, but can easily be reproduced under Linux as done in this case) [andris@localhost test]$ ../xgcc -B ../ -c -remap foo.c remap_filename: fname='foo.c' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='foo/bar/baz.h' remap_filename: new_dir='foo/' remap_filename: new_dir='foo/bar/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='../includesys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='../include-fixedsys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='/usr/local/includesys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='/usr/includesys/' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='sys/cdefs.h' remap_filename: new_dir='../includesys/' remap_filename: fname='sys/cdefs.h' remap_filename: new_dir='../include-fixedsys/' remap_filename: fname='sys/cdefs.h'
[Bug target/71286] 6.1.0: compiling djgpp programs with LTO emits "visibility attribute not supported in this configuration" warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71286 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #3 from Andris Pavenis --- I have only tried -flto for DJGPP in case of native compiler. In this case LTO only have limited functionality due to absence of plugin and as result modules read by linker from static libraries are left out from optimization as far as I understand. At least -flto seems to work in this limited case (several object files) for native DJGPP compiler
[Bug fortran/69043] Trying to include a directory causes an infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #6 from Andris Pavenis --- Breaks include support for DJGPP native compiler as S_ISREG is 0 for it. One should use S_ISREG(st.st_mode) instead. gcc/system.h ensures that S_ISREG is defined, so there should be no problems with it. Verified that replacing '(st.st_mode & S_IFREG)' with S_ISREG(st.st_mode) fixes libgfortran native build for DJGPP.
[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Andris Pavenis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andris Pavenis --- Tried gcc-5.1.0 and gcc-5.3.0 with software where bug was initially detected with workaround reverted. Results: - SIGSEGV with gcc-4.9.3 as earlier - no failures with gcc-5.1.0 and gcc-5.3.0 So I'm closing this big as fixed
[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Andris Pavenis changed: What|Removed |Added Known to fail|4.8.2, 4.9.0|4.8.5, 4.9.3 --- Comment #2 from Andris Pavenis --- I cannot reproduce problem with: - gcc-versio 6.0.0 20151222 (experimental) (GCC) - gcc-versio 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) on Fedora 23 x86_64 (tried also -m32) I can still reproduce it with my builds of gcc-4.8.5 and gcc-4.9.3. So it seems that the problem is fixed
[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557 --- Comment #5 from Andris Pavenis --- I have just committed to SVN trunk very similar patch (but not identical)for djgpp-stdint.h (revision 231804)
[Bug driver/68181] djgpp: minor linker invocation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68181 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #1 from Andris Pavenis --- Linker script djgpp.djl have not been used any more for DJGPP port for very long time. The problem is that DJGPP related changes have not been git into official GCC sources. Current version of djgpp.h and other related DJGPP files are rather different from official ones. Built cross-compiler from trunk version today (Centos 6 x86_64). Currently native DJGPP build is ongoing. Most configuration changes do not touch other stuff except avoiding using LINK_COMMAND_SPEC. I defined additional POST_LINK_SPEC in gcc/gcc.c and that could be a problem in current time. So I need finally try to get changes into GCC sources (at least part of them)
[Bug ada/65259] Failure to build Ada DVI and PDF documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65259 --- Comment #4 from Andris Pavenis --- Now it is OK. Thanks.
[Bug ada/65259] New: Failure to build Ada DVI and PDF documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65259 Bug ID: 65259 Summary: Failure to build Ada DVI and PDF documentation Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Created attachment 34908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34908&action=edit 'make dvi' output ilustrating documentation build failure Noticed that make pdf and make dvi fail for gcc version 5.0.0 20150301 (experimental) (GCC) configured with Ada compiler enabled I did not have this problem with gcc version 5.0.0 20150202 (experimental) (GCC)
[Bug libstdc++/64553] Missing '# ifdef _GLIBCXX_USE_WCHAR_T' in src/c++11/cxx11-shim_facet.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64553 --- Comment #1 from Andris Pavenis --- Created attachment 34415 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34415&action=edit A patch After included patch for cxx11-shim_facets.cc native bootstrap succeeded for DJGPP (C, C++, Fortran, Objc, ObjC++). There were however other DJGPP related changes
[Bug libstdc++/64553] New: Missing '# ifdef _GLIBCXX_USE_WCHAR_T' in src/c++11/cxx11-shim_facet.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64553 Bug ID: 64553 Summary: Missing '# ifdef _GLIBCXX_USE_WCHAR_T' in src/c++11/cxx11-shim_facet.cc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi wchar related defines are exposed in the new std::string implementation even if wchar.h is not fully usable (_GLIBCXX_USE_WCHAR_T not defined). The result is bootstrap stage 2 failure due to unresolved external references. Noticed this when trying to bootstrap GCC for DJGPP
[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 --- Comment #1 from Andris Pavenis --- Reproduced also with gcc-5.0 20141123 snapshot on Linux x86_64
[Bug c++/60585] New: Virtual function related memory access errors with multiple virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Bug ID: 60585 Summary: Virtual function related memory access errors with multiple virtual inheritance Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Created attachment 32392 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32392&action=edit Simplified C++ test example The attached reduced example causes valgrind to complain about access to uninitialized value when built with gcc-4.9.0 20140318 on Linux (both i86 and x86_64, included output is from 32 bit version): andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -O2 -Wall -Wextra virtual.cpp andpav@andris-HP-Z230:~/Tests/2014-03-18$ valgrind ./a.out ==10812== Memcheck, a memory error detector ==10812== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==10812== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==10812== Command: ./a.out ==10812== ==10812== Use of uninitialised value of size 4 ==10812==at 0x80484C6: virtual thunk to F::f() const (in /home/andpav/Tests/2014-03-18/a.out) ==10812==by 0x8048379: main (in /home/andpav/Tests/2014-03-18/a.out) ==10812== ==10812== ==10812== HEAP SUMMARY: ==10812== in use at exit: 0 bytes in 0 blocks ==10812== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==10812== ==10812== All heap blocks were freed -- no leaks are possible ==10812== ==10812== For counts of detected and suppressed errors, rerun with: -v ==10812== Use --track-origins=yes to see where uninitialised values come from ==10812== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -v Using built-in specs. COLLECT_GCC=g++-4.9 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.9.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.9-20140318/configure --program-suffix=-4.9 --enable-languages=c,c++ --enable-lto Thread model: posix gcc version 4.9.0 20140318 (experimental) (GCC) There are also ocasional crashes (SIGSEGV) in real software from which the reduced example has been created. Also reproduced with gcc-4.8 (Fedora 20 x86_64 and Ubuntu 13.10 i686) and gcc-4.7 (Ubuntu-13.10 i686). Does not happen with gcc-4.6 (Ubuntu 12.04) Also specifying -fno-inline-small-functions together with -O2 or -O3 for affected gcc versions make the problem not happen (both reduced example and real software)
[Bug rtl-optimization/56356] [4.7/4.8/4.9 Regression] DJGPP compiler crashing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56356 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #3 from Andris Pavenis --- The problem could perhaps be that rather many changes I use for building cross-compiler for DJGPP target are not in official GCC source tree. I have never seen similar problem myself. For me cross-compiler with mentioned changes builds OK for last versions including current development sources (last tested with 2014-03-02 snapshot) For GCC releases changes can be found from ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-*/djcross-gcc-*.tar.bz2 (substitute version) together with required scripts For last development sources I have tried changes are at address: http://ap1.pp.fi/djgpp/gcc/test/4.9.0-20140302/src/djcross-gcc-4.9.0_20140302.tar.bz2 I myself use rpmbuild for building cross-compiler (CentOS or Fedora). Others have tried for different systems (see https://github.com/andrewwutw/build-djgpp). I myself have not tested that
[Bug other/58348] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348 --- Comment #5 from Andris Pavenis --- It was short term bug as ENABLE_VTABLE_VERIFY was removed from libvtv/configure.ac and libvtv/Makefile.am at first and left in libvtv/testsuite/Makefile.am. It was removed from last place 4 days later. So there is no need to recheck anything. The bug could have be closed already in September
[Bug other/58348] Build fails on x86_64-unknown-linux-gnu in libvtv on ENABLE_VTABLE_VERIFY not in AM_CONDITIONAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot fi --- Comment #3 from Andris Pavenis --- Also run into the same problem: Test if ENABLE_VTABLE_VERIFY has been removed from libvtv/Makefile.am but not libvtv/testsuite/Makefile.am.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #36 from Andris Pavenis 2013-02-14 04:25:17 UTC --- This way does not work for DJGPP v2.03 (version v2.04pre is OK). For DJGPP v2.03: AC_PROG_LN_S tries 'ln -s', which do not work, after that it falls back to simple 'ln' which creates copy of file (acts as 'cp'). As the result we'll getting LN_S=ln in Makefile Correct way should be detecting whether ln -s works for directories in configure script and adding corresponding substitution for Makefile.in for LN_S_RECURSIVE like LN_S_RECURSIVE=@LN_S_RECURSIVE@ Tests could look like: - create directory and file in the it - try to create symlink to directory and look whether it succeeds - check for presence of the file through symlink Less pedantic way could be avoiding using file in subdirectory and relaying on success of 'ln -s' only.
[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557 --- Comment #3 from Andris Pavenis 2013-01-16 18:57:42 UTC --- I also verified that I have already mostly applied a patch sent to gcc-bugs recently (http://gcc.gnu.org/ml/gcc-bugs/2013-01/msg01142.html) already for my builds, except of course one typo in the patch: +#define INT_FAST16_TYPE "int" I do not remeber any more why it was done. It would also have been be faster to report problem also to DJGPP mailing list.
[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot ||fi --- Comment #2 from Andris Pavenis 2013-01-16 18:33:01 UTC --- I do not remeber that I ever have seen this problem. It looks that in the first case (message from 2009-10-03) my build for DJGPP v2.03 has been used. For that case I would suggest to remove command line option -fpch-preprocess. I initially had problem using PCH for DJGPP and after that I always used --disable-pch. About second message: Are You using unmodified gcc sources on Ubuntu? All builds of GCC for DJGPP has additional changes to the original sources (I know it would be nice to have changes submitted). For ubunto one could try to use alien to convert my RPM packages available from ftp://ftp.delorie.com/pub/djgpp/rpms (or my latest test build at http://ap1.pp.fi/djgpp/gcc/test/4.8.0-20130111/) to .deb (I'm specially performing RPM builds to reduce possible dependence on system as much as possible so it is rather likely that packages should work on Ubuntu after converted to .deb)
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot ||fi --- Comment #8 from Andris Pavenis 2012-09-23 05:56:08 UTC --- One also needs LN_S = cp -pr for DJGPP (v 2.0.3 only, current development version supports symlinks)
[Bug target/47099] i686-pc-msdosdjgpp fails to build i386.o: ASM_DECLARE_FUNCTION_NAME undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47099
Andris Pavenis changed:
What|Removed |Added
CC||andris.pavenis at iki dot
||fi
--- Comment #3 from Andris Pavenis 2012-09-22
08:47:25 UTC ---
(In reply to comment #2)
> ../../../gcc/gcc/config/i386/i386.c: In function ‘void ix86_code_end()’:
> ../../../gcc/gcc/config/i386/i386.c:8855:55: error:
> ‘ASM_DECLARE_FUNCTION_NAME’
> was not declared in this scope
> ASM_DECLARE_FUNCTION_NAME (asm_out_file, name, decl);
>^
> make[2]: *** [i386.o] Error 1
Adding lines like
#undef ASM_DECLARE_FUNCTION_NAME
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
do { \
ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL); \
} while (0)
to gcc/config/i386/djgpp.h should fix that for DJGPP target
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #4 from Andris Pavenis 2012-09-09 16:47:44 UTC --- My test was done with DJGPP development version (2.04) only. It has stdint.h, but it was recognized by configure as unusable due to bug unrelated to GCC itself. After fixing this problem locally libstdc++-v3 builds OK for DJGPP v2.04 (only tested cross-native build from Linux) Stable version DJGPP v2.03 does not have stdint.h As the result I agree with the suggestion in comment 3 to completely disable random.cc when _GLIBCXX_USE_C99_STDINT_TR1 is not defined Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later)
[Bug libstdc++/54451] New: c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Bug #: 54451 Summary: c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: andris.pave...@iki.fi When _GLIBCXX_USE_C99_STDINT_TR1 defined in config.h neither of bits/random.h and bits/random.tcc gets included and as result c++11/random.cc does not compile: random.cc:72:3: error: 'random_device' has not been declared Noticed that when trying to build recent SVN version as Linux to DJGPP cross-compiler. Tested versions 2012-08-30 and later. Commenting out '#ifdef _GLIBCXX_USE_C99_STDINT_TR1' fixed build problem, but I'm not sure that it is correct solution.
[Bug bootstrap/53709] New: libada build failure when bootstrapping on Fedora 17 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53709 Bug #: 53709 Summary: libada build failure when bootstrapping on Fedora 17 x86_64 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: andris.pave...@iki.fi Created attachment 27645 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27645 build output compressed with xz Noticed that 'make bootstrap" for gcc-4.7.1 release fails when building all-target-libada on Fedora 17 x86_64. Initially found with modified GCC sources, but reproduced also with original ones. Only C, C++ and Ada languages were enabled. Output ends with: -Wl,-soname,libgnat-4.7.so \ -lm /usr/bin/ld: adadecode.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC adadecode.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[5]: *** [gnatlib-shared-default] Error 1 make[5]: Leaving directory `/home/andris/2/build/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/home/andris/2/build/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/home/andris/2/build/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/home/andris/2/build/x86_64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/home/andris/2/build' make: *** [bootstrap] Error 2 Full XZ packed build output attached (when building from original gcc-4.7.1 sources)
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 --- Comment #2 from Andris Pavenis 2012-05-14 11:30:49 UTC --- Created attachment 27400 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27400 Add missing sub-package to s-taprop-dummy.adb
[Bug other/52992] New: Incorrect sprintf format in fixincludes/fixincl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52992 Bug #: 52992 Summary: Incorrect sprintf format in fixincludes/fixincl.c Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andris.pave...@iki.fi Created attachment 27158 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27158 Fix for sprintf format fixincludes/fixinc.c caontains incorrect format string for sprintf: sprintf (pz_scan, " %ld '%s' '%s'", (long) (p_fixd - fixDescList), pz_fix_file, pz_file_source, pz_temp_file); (3 paramaters in format, 4 in argumnent list) Noticed in 4.6.3 when djgpp_wchar_h fix failed to be executed. The same bug present also in current trunk.
[Bug ada/52494] New: s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 Bug #: 52494 Summary: s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: andris.pave...@iki.fi s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb which causes compile to fail if s-taprop-dummy.adb is chosen for target. Adding simple subpackage which only contains procedure Set seems to be sufficient in this case (not yet tested more rather than s-tpoaal.adb compiles then) (tried to compile as cross-compiler from Linux for target i586-pc-msdosdjgpp)
[Bug c++/51320] gcc internal compiler error (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51320 --- Comment #15 from Andris Pavenis 2011-11-28 05:18:21 UTC --- (In reply to comment #14) > Verify that You have > > c:/djc462~1/libexec/gcc/djgpp/4.62/cc1plus.exe at all > > (I suspect that it is not there due missing installation of gpp462b.zip > package and use of obsolete GCC wrapper program c:/djc462~1/bin/gxx.exe). > If so than install gpp462b.zip) > > Also: inability to invoke C++ compiler at all indicates installation not > compiler error. The discussions about installation errors should happen in > DJGPP mailing list not here. So I suggest closing this bug as INVALID Crash of gcc -print-prog-name=cc1plus shows that something is very wrong. Anyway better place to discuss these things is DJGPP mailing list.
[Bug c++/51320] gcc internal compiler error (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51320 --- Comment #14 from Andris Pavenis 2011-11-28 04:43:41 UTC --- Verify that You have c:/djc462~1/libexec/gcc/djgpp/4.62/cc1plus.exe at all (I suspect that it is not there due missing installation of gpp462b.zip package and use of obsolete GCC wrapper program c:/djc462~1/bin/gxx.exe). If so than install gpp462b.zip) Also: inability to invoke C++ compiler at all indicates installation not compiler error. The discussions about installation errors should happen in DJGPP mailing list not here. So I suggest closing this bug as INVALID
[Bug c++/51320] gcc internal compiler error (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51320 --- Comment #7 from Andris Pavenis 2011-11-27 07:36:29 UTC --- Tested with native compiler for DJGPP both versions 2.03r2 and 2.04 pre. Compiles OK for both with and without optimization enabled (tried without, with -O2 and with -O3). I tested in DOS session under Windows Vista Business XP2 (32 bit) Also compiles OK with - Linux to DJGPP cross-compiler (GNU C++ (GCC) version 4.6.2 (i586-pc-msdosdjgpp)) - native compiler for Linux x86_64 (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)) >From last attachment it seems that GCC fails very early not finding even cc1plus. So I suspect a problem with DJGPP installation. I would suggest to - Run 'gcc -print-prog-name=cc1plus' and see what it outputs. If it outputs only 'cc1plus' without full path then the GCC installation is broken - test whether You can compiler any C and C++ program at all - create a paralell fresh DJGPP installation with only required packages and retest
[Bug c++/51320] gcc internal compiler error (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51320 Andris Pavenis changed: What|Removed |Added CC||andris.pavenis at iki dot ||fi --- Comment #6 from Andris Pavenis 2011-11-27 07:17:35 UTC --- (In reply to comment #4) > djgpp has a problem with the new 4.6.2 compiler where it is unable to generate > any temp files with -save-temps. sorry. I cannot reproduce this problem. -save-temps works for me as expected. Tested both versions from current and beta in DOS session under Windows Vista Business SP2 32 bit.
