[Bug libstdc++/60623] New: FAIL: libstdc++-abi/abi_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60623 Bug ID: 60623 Summary: FAIL: libstdc++-abi/abi_check Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu spawn /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/ src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/da ve/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/g nu/gcc/gcc-4.9/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/sys-include -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdi r/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/ util/testsuite_abi_check.cc -w ./libtestc++.a -Wl,--gc-sections -lm -o abi_checkSetting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hpp a-linux-gnu/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc spawn [open ...] 40 added symbols 0 _ZNKSt20bad_array_new_length4whatEv std::bad_array_new_length::what() const version status: compatible CXXABI_1.3.8 type: function status: added 1 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEjjj std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned int, unsigned int, unsigned int) const version status: incompatible GLIBCXX_3.4.18 type: function status: added 2 _ZNSt20bad_array_new_lengthD0Ev std::bad_array_new_length::~bad_array_new_length() version status: compatible CXXABI_1.3.8 type: function status: added 3 _ZTISt16bad_array_length typeinfo for std::bad_array_length version status: compatible CXXABI_1.3.8 type: object type size: 12 status: added 4 _ZNSt16bad_array_lengthD0Ev std::bad_array_length::~bad_array_length() version status: compatible CXXABI_1.3.8 type: function status: added 5 _ZNSt13random_device16_M_getval_pretr1Ev std::random_device::_M_getval_pretr1() version status: incompatible GLIBCXX_3.4.18 type: function status: added 6 _ZNSt13random_device9_M_getvalEv std::random_device::_M_getval() version status: incompatible GLIBCXX_3.4.18 type: function status: added 7 _ZNSt11regex_errorC1ENSt15regex_constants10error_typeE std::regex_error::regex_error(std::regex_constants::error_type) version status: compatible GLIBCXX_3.4.20 type: function status: added 8 _ZSt14get_unexpectedv std::get_unexpected() version status: compatible GLIBCXX_3.4.20 type: function status: added 9 _ZNSt13random_device7_M_initERKSs std::random_device::_M_init(std::string const&) version status: incompatible GLIBCXX_3.4.18 type: function status: added 10 _ZSt24__throw_out_of_range_fmtPKcz std::__throw_out_of_range_fmt(char const*, ...) version status: compatible GLIBCXX_3.4.20 type: function status: added 11 _ZNSt20bad_array_new_lengthD2Ev std::bad_array_new_length::~bad_array_new_length() version status: compatible CXXABI_1.3.8 type: function status: added 12 _ZTSSt20bad_array_new_length typeinfo name for std::bad_array_new_length version status: compatible CXXABI_1.3.8 type: object type size: 25 status: added 13 _ZTISt20bad_array_new_length typeinfo for std::bad_array_new_length version status: compatible CXXABI_1.3.8 type: object type size: 12 status: added 14 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIxSt5ratioILx1ELx1NS1_IxS2_ILx1ELx10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: incompatible GLIBCXX_3.4.18 type: function status: added 15 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj std::__detail::_Prime_rehash_policy::_M_nex
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 --- Comment #3 from Dominique d'Humieres --- (In reply to comment #1) > Adding to my list Do you mean that you assign this PR to you?
[Bug fortran/37355] Request runtime preconnected buffer option for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37355 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Dominique d'Humieres --- Does not seem assigned.
[Bug c/60622] New: [4.9 Regression] symbol missing when compiled with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60622
Bug ID: 60622
Summary: [4.9 Regression] symbol missing when compiled with
-flto
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
trying to compile systemd with gcc 4.9 snapshot there appears to be a lot of
undefined symbols, I traced it down to the fact that system uses -flto option
during compilation, and when thats used the symbol table is completely bald.
e.g.
extern int arg;
__attribute__ ((visibility("default"))) extern int foo() {
return arg;
}
$ mips-angstrom-linux-uclibc-gcc test.c -c -flto
$ readelf -s test.o
Symbol table '.symtab' contains 19 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT6
6: 0 SECTION LOCAL DEFAULT7
7: 0 SECTION LOCAL DEFAULT8
8: 0 SECTION LOCAL DEFAULT9
9: 0 SECTION LOCAL DEFAULT 10
10: 0 SECTION LOCAL DEFAULT 11
11: 0 SECTION LOCAL DEFAULT 12
12: 0 SECTION LOCAL DEFAULT 13
13: 0 SECTION LOCAL DEFAULT4
14: 0 SECTION LOCAL DEFAULT5
15: 0 SECTION LOCAL DEFAULT 14
16: 0 SECTION LOCAL DEFAULT 15
17: 0001 1 OBJECT GLOBAL DEFAULT COM __gnu_lto_v1
18: 0001 1 OBJECT GLOBAL DEFAULT COM __gnu_lto_slim
$ mips-angstrom-linux-uclibc-gcc test.c -c
$ readelf -s test.o
Symbol table '.symtab' contains 13 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 SECTION LOCAL DEFAULT8
6: 0 SECTION LOCAL DEFAULT5
7: 0 SECTION LOCAL DEFAULT6
8: 0 SECTION LOCAL DEFAULT9
9: 0 SECTION LOCAL DEFAULT 10
10: 52 FUNCGLOBAL DEFAULT1 foo
^^^
symbol is there
11: 0 NOTYPE GLOBAL DEFAULT UND __gnu_local_gp
12: 0 NOTYPE GLOBAL DEFAULT UND arg
This issue I did not see on arm, only on ppc and mips
here gcc configure
Target: mips-angstrom-linux-uclibc
Configured with:
/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/work-shared/gcc-4.9-20140316-r0/gcc-4.9-20140316/configure
--build=x86_64-linux --host=x86_64-linux --target=mips-angstrom-linux-uclibc
--prefix=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr
--exec_prefix=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr
--bindir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/bin/mips32-angstrom-linux-uclibc
--sbindir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/bin/mips32-angstrom-linux-uclibc
--libexecdir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/libexec/mips32-angstrom-linux-uclibc
--datadir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/share
--sysconfdir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/etc
--sharedstatedir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/com
--localstatedir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/var
--libdir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/lib/mips32-angstrom-linux-uclibc
--includedir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include
--oldincludedir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include
--infodir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/share/info
--mandir=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/home/kraj/angstrom/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix
[Bug fortran/54070] [4.8/4.9 Regression] Wrong code with allocatable deferred-length (array) function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW Summary|Wrong code with allocatable |[4.8/4.9 Regression] Wrong |deferred-length (array) |code with allocatable |function results|deferred-length (array) ||function results --- Comment #6 from Dominique d'Humieres --- > Should I mark this pr as a 4.8/4.9 regression? No answer, marking as a 4.8/4.9 regression.
[Bug fortran/49802] [F2003, F2008] Wrong code with VALUE, F2008: VALUE with arrays/DIMENSION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Dominique d'Humieres --- No idea why I set it to WAITING, moved to NEW.
[Bug fortran/42945] Gcov -a fails on Fortan generated object file (infinite loop?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Dominique d'Humieres --- No reply since 9 months, inactive since more than 4 years. Closing as WORSFORME.
[Bug libfortran/35667] HP-UX 10 has broken strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35667 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > > Was that fixed with John's commit? > I think so. I believe this was left open because the patch wasn't > back ported. The patch was committed in 4.6 or 4.7 (3 years ago), so the back porting issue in now moot. Closing as FIXED.
[Bug fortran/59537] No "Automatic array cannot have an initializer", for -finit-real without a SAVE statement present in subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537 Dominique d'Humieres changed: What|Removed |Added Summary|"An automatic object shall |No "Automatic array cannot |not have the SAVE |have an initializer", for |attribute." is not |-finit-real without a SAVE |diagnosed. |statement present in ||subroutine --- Comment #5 from Dominique d'Humieres --- > real :: a(1:n) > save > > in which case the "SAVE" statement should apply to all variables to which > it can apply - that is _not_ to the automatic dummy argument "a". You are right: 5.4.14 SAVE statement ... 1 A SAVE statement with a saved entity list speci es the SAVE attribute (5.3.16) for a list of entities. A SAVE statement without a saved entity list is treated as though it contained the names of all allowed items in the same scoping unit. I thought that the SAVE statement applied to ALL local variables, my bad. > Nonetheless, code that compiles without -finit-real should also compile > with -finit-real, right? I disagree: C506 states that automatic object cannot be initialized. What is wrong is that it depends on the presence of the SAVE statement without a saved entity list.
[Bug libstdc++/60621] New: std::vector::emplace_back generates massively more code than push_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
Bug ID: 60621
Summary: std::vector::emplace_back generates massively more
code than push_back
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mutz at kde dot org
Created attachment 32429
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32429&action=edit
Source of the programme used to generate the mentioned numbers
Compiling the attached program on Linux AMD64 with the following command lines:
$ g++ -O2 -std=c++11 -o emplace-vs-push_back{.pb,.cpp}
$ g++ -O2 -std=c++11 -o emplace-vs-push_back{.eb,.cpp} -DEMPLACE_BACK
and stripping the resulting executables:
$ strip emplace-vs-push_back.*
I get the following sizes:
$ size emplace-vs-push_back.*
textdata bss dec hex filename
5570 696 40630618a2 emplace-vs-push_back.eb
4338 672 40505013ba emplace-vs-push_back.pb
IOW: the emplace_back version generates roughly 1K more text (code).
This is surprising, since functionally, emplace_back is the same as
push_back(S&&), except that it saves one move ctor and one dtor call due to
in-place construction. This should result in _less_ code generated, not more.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dominique d'Humieres --- > Is this PR fixed or not? No answer since 9 months, no activity since 6 years. Closing as FIXED. Please open a new PR for remaining issues.
[Bug fortran/59537] "An automatic object shall not have the SAVE attribute." is not diagnosed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537 --- Comment #4 from Lorenz Hüdepohl --- > From the above gfortran is right to reject the code with initialization. > > > Without the SAVE statement it compiles fine. > > From the above (C513) this is a bug, the code should give an error > without/with -finit-*. I guess my point is, that I do _not_ specify real, save :: a(1:n) which would be illegal, but merely real :: a(1:n) save in which case the "SAVE" statement should apply to all variables to which it can apply - that is _not_ to the automatic dummy argument "a". Nonetheless, code that compiles without -finit-real should also compile with -finit-real, right?
[Bug rtl-optimization/60601] [4.9 Regression] profiledbootstrap fails with Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60601 --- Comment #4 from Eric Botcazou --- The next error is: In file included from /home/eric/svn/gcc/gcc/gcc.c:36:0: /home/eric/svn/gcc/gcc/../include/obstack.h: In function 'const char* handle_spec_function(const char*, bool*)': /home/eric/svn/gcc/gcc/../include/obstack.h:337:52: error: 'save_growing_value' may be used uninitialized in this function [-Werror=maybe-uninitialized] _obstack_memcpy (__o->next_free, (where), __len); \ ^ /home/eric/svn/gcc/gcc/gcc.c:5484:9: note: 'save_growing_value' was declared here void *save_growing_value;
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- >From comment #13 > Could this PR be closed as FIXED? No answer for over 9 months and no activity for almost 3 years. Closing as FIXED. Please open a new PR for remaining issues.
[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52176 --- Comment #3 from Dominique d'Humieres --- With valgrind 3.7.0 and gfortran 4.9.0 r208594, I no longer see the Conditional jump or move depends on uninitialized value if I don't use -flto, while I still see them with 4.8.2. Note the errors are back for 4.9 if I compile with -flto. I all cases I see some "... blocks are still reachable in loss record ..." messages related to I/Os (in write_float).
[Bug rtl-optimization/60601] [4.9 Regression] profiledbootstrap fails with Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60601 --- Comment #3 from Eric Botcazou --- fix_up_fall_thru_edges is apparently looking for EDGE_CAN_FALLTHRU edges but this flag is only set during bb-reorder. Testing trivial patch.
[Bug fortran/60477] unlimited type class(*) not working properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60477 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- Based on comments 1 and 2, closing as FIXED.
[Bug rtl-optimization/60601] [4.9 Regression] profiledbootstrap fails with Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60601 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- The code in comment 0 compiles for me with 4.8.2 and trunk. It is rejected by 4.7.4 with pr51292.f90:5.27: function bar (a) result (h) 1 Error: Function result 'h' at (1) cannot have an initializer (twice, changed to only once between r190090 and r195731). The error disappeared between r195931 and r196108. Could this PR be closed as fixed?
[Bug fortran/59537] "An automatic object shall not have the SAVE attribute." is not diagnosed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537 Dominique d'Humieres changed: What|Removed |Added Keywords||accepts-invalid Summary|"Automatic array cannot |"An automatic object shall |have an initializer", for |not have the SAVE |-finit-real and a SAVE |attribute." is not |statement present in|diagnosed. |subroutine | --- Comment #3 from Dominique d'Humieres --- > Maybe related to the already fixed #51800? The difference is that in pr51800 the array is a dummy argument, while here it is an automatic array. Looking at the f2008 standard, I see 5.2 Type declaration statements 5.2.1 Syntax ... C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable variable, an external function, an intrinsic function, or an automatic object. ... 5.2.2 Automatic data objects An automatic data object is a nondummy data object with a type parameter or array bound that depends on the value of a speci cation-expr that is not a constant expression. C513 An automatic object shall not have the SAVE attribute. ... From the above gfortran is right to reject the code with initialization. > Without the SAVE statement it compiles fine. >From the above (C513) this is a bug, the code should give an error without/with -finit-*.
[Bug fortran/49331] Accepts invalid specification expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49331 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- For the second test in comment 1, I get the following errors (r208766) pr49331_1.f90:11.30: character(kind=kind(LEN())) :: one 1 Error: Kind 0 is not supported for CHARACTER at (1) pr49331_1.f90:12.10: one = '' 1 Error: Can't convert CHARACTER(1) to REAL(4) at (1) but nor error for iso_varying_string.f95 compiled with -std=f2003.
[Bug fortran/47648] libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory - FreeBSD ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- Is it still a problem?
[Bug fortran/46020] Improve error string for BIND(C) diagnostic for len>1 character return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46020 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #8 from Dominique d'Humieres --- Related to pr46496.
[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at r208766.
[Bug fortran/47605] Document that C_Bool might be the wrong constant for C Booleans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47605 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- In [1] I see > For logical types, please note that the Fortran standard only guarantees > interoperability between C99's _Bool and Fortran's C_Bool-kind logicals and > C99 > defines that true has the value 1 and false the value 0. Using any other > integer > value with GNU Fortran's LOGICAL (with any kind parameter) gives an undefined > result. (Passing other integer values than 0 and 1 to GCC's _Bool is also > undefined, unless the integer is explicitly or implicitly casted to _Bool.) What should be added to that?
[Bug fortran/55758] LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55758 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- What remains to be fixed? If anything, is it related to pr47605?
[Bug fortran/55849] [OOP] Implement temporary support for SELECT TYPE(name => array ( [vector-subscript] ))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55849 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at r208766.
[Bug fortran/57079] [Fortran-dev] version/type/attribute fields not set with CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57079
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-03-22
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres ---
What is the problem with this pr? The difference between the dump with trunk
(r208766) and the dev branch (r208422) is
--- pr57079.f90.003t.original2014-03-22 20:11:30.0 +0100
+++ pr57079.f90_dev.003t.original2014-03-22 20:10:59.0 +0100
@@ -14,28 +14,38 @@ foo ()
try
{
x = 0B;
- if (x != 0B)
+ if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (x != 0B), 0))
{
_gfortran_runtime_error_at (&"At line 10 of file pr57079.f90"[1]{lb:
1 sz: 1}, &"Attempting to allocate already allocated variable \'%s\'"[1]{lb: 1
sz: 1}, &"x"[1]{lb: 1 sz: 1});
}
else
{
- x = (struct t *) __builtin_malloc (112);
- if (x == 0B)
+ x = (struct t *) __builtin_malloc (128);
+ if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (x == 0B),
0))
{
_gfortran_os_error (&"Allocation would exceed memory
limit"[1]{lb: 1 sz: 1});
}
}
- x->x.data = 0B;
- x->y._data.data = 0B;
+ x->x.base_addr = 0B;
+ x->x.elem_len = 4;
+ x->x.version = 1;
+ x->x.rank = 1;
+ x->x.type = 1025;
+ x->x.attribute = 2;
+ x->y._data.base_addr = 0B;
+ x->y._data.elem_len = 0;
+ x->y._data.version = 1;
+ x->y._data.rank = 1;
+ x->y._data.type = -1;
+ x->y._data.attribute = 1;
{
struct t t.0;
if (x != 0B) goto L.1;
-x = (struct t *) __builtin_calloc (1, 112);
+x = (struct t *) __builtin_calloc (1, 128);
L.1:;
-t.0.x.data = 0B;
-t.0.y._data.data = 0B;
+t.0.x.base_addr = 0B;
+t.0.y._data.base_addr = 0B;
t.0.y._vptr = (struct __vtype_foo_T2 * {ref-all}) &__vtab_foo_T2;
t.0.z = 55;
*x = t.0;
@@ -45,20 +55,20 @@ foo ()
{
if (x != 0B)
{
- if (x->x.data != 0B)
+ if (x->x.base_addr != 0B)
{
- __builtin_free ((void *) x->x.data);
+ __builtin_free ((void *) x->x.base_addr);
}
- x->x.data = 0B;
- if ((struct t2[0:] * restrict) x->y._data.data != 0B &&
x->y._vptr->_final != 0B)
+ x->x.base_addr = 0B;
+ if ((struct t2[0:] * restrict) x->y._data.base_addr != 0B &&
x->y._vptr->_final != 0B)
{
x->y._vptr->_final (&x->y._data, (integer(kind=8))
x->y._vptr->_size, 1);
}
- if (x->y._data.data != 0B)
+ if (x->y._data.base_addr != 0B)
{
- __builtin_free ((void *) x->y._data.data);
+ __builtin_free ((void *) x->y._data.base_addr);
}
- x->y._data.data = 0B;
+ x->y._data.base_addr = 0B;
__builtin_free ((void *) x);
}
}
[Bug fortran/60334] Segmentation fault on character pointer assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed at r208594.
[Bug fortran/47506] [OOP][Fortran 90+] Assumed-size array checks (polymorphic and component)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47506 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Wrong link. No error when compiling the test in a with r208766.
[Bug target/60582] gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582 Dominique d'Humieres changed: What|Removed |Added Component|fortran |target --- Comment #1 from Dominique d'Humieres --- As said in pr60128, this is a quality of implementation deficiency in the quadmath library: all the real kinds are rounded to nearest, but real(16) which is rounded towards zero.
[Bug bootstrap/36815] gnattools related error when building only c and fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36815 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Jerry DeLisle --- Old report
[Bug bootstrap/30830] Bootstrap failure in stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30830 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jerry DeLisle --- Closing
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Jerry DeLisle --- Several years have passed. Closing
[Bug libfortran/46800] Handle CTRL-D correctly with STDIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46800 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerry DeLisle --- Fixed on trunk, closing.
[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60613 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60613 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Sat Mar 22 16:25:50 2014 New Revision: 208766 URL: http://gcc.gnu.org/viewcvs?rev=208766&root=gcc&view=rev Log: PR sanitizer/60613 * internal-fn.c (ubsan_expand_si_overflow_addsub_check): For code == MINUS_EXPR, never swap op0 with op1. * c-c++-common/ubsan/pr60613-1.c: New test. * c-c++-common/ubsan/pr60613-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr60613-1.c trunk/gcc/testsuite/c-c++-common/ubsan/pr60613-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56491] [OOP] Memory leak with vtab's type-bound-procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56491 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- On darwin10, r208594, I get ==84656== 4 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==84656==at 0x100012679: malloc (vg_replace_malloc.c:266) ==84656==by 0x10C90: MAIN__ (in ./a.out) ==84656==by 0x10D87: main (in ./a.out)
[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.6 to trunk (4.9).
[Bug fortran/59202] Erroneous argument aliasing with defined assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Behavior still present at r208765.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 tim.lebedkov at gmail dot com changed: What|Removed |Added CC||tim.lebedkov at gmail dot com --- Comment #11 from tim.lebedkov at gmail dot com --- Qt 5.2.1 cannot be build in 32 bit with mingw-w64 4.8.2 because of this bug. Why is it not fixed?
[Bug fortran/58620] [OOP] Defined assignment not called for TYPE when the type's extension is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58620 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at r208765.
[Bug fortran/58644] [OOP] Missing .data ref in passing a CLASS array as actual argument to a TYPE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58644 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I don't understand this PR. The test succeeds even when compiled with -fsanitize=address.
[Bug fortran/58331] [OOP] Bogus rank checking with explicit-/assumed-size arrays and CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58331 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- With the patch in comment 2, I also get (r208765) pr58331.f90: In function 'upv': pr58331.f90:19:0: error: non-trivial conversion at assignment program upv ^ struct array1_unknown struct array2_integer(kind=4) class.6._data = parm.7; pr58331.f90:19:0: internal compiler error: verify_gimple failed I also get the same ICE if I use class(*), intent(in) :: a(..) ... print *, rank(a)
[Bug fortran/58189] Color diagnostics for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58189 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- (In reply to Tobias Burnus from comment #2) > It is not really middle-end, but yes re-using common infrastructure (instead > of > duplicating it) would be nice. Agreed!
[Bug fortran/55850] [OOP] SELECT TYPE issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- As for r208743, compiling the first test gives the following error select type (component => self%cb(1)[4]) ! INVALID due to the "[4]" 1 Error: Selector at (1) must not be coindexed Compiling the second test no longer gives an ICE, but the errors select type (t = self%cb) 1 Error: parse error in SELECT TYPE statement at (1) pr55850_1.f90:12.7: end select 1 Error: Expecting END FUNCTION statement at (1) Same thing for the third test select type (t => self%cb) 1 Error: Symbol 't' at (1) has no IMPLICIT type pr55850_2.f90:11.30: select type (t => self%cb) 1 Error: Selector shall be polymorphic in SELECT TYPE statement at (1) although I am not sure about the errors for the later test. I get the same behavior with 4.8.3. With 4.7.4, I get pr55850.f90:10.34: class (tn), intent(in) :: self 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar pr55850.f90:10.34: class (tn), intent(in) :: self 1 Error: Variable 'dst' at (1) is INTENT(OUT) and can thus not be an allocatable coarray or have coarray components pr55850.f90:10.34: class (tn), intent(in) :: self 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar pr55850_1.f90:11.4: select type (t = self%cb) 1 Error: Unclassifiable statement at (1) pr55850_1.f90:12.7: end select 1 Error: Expecting END FUNCTION statement at (1) pr55850_2.f90:11.30: select type (t => self%cb) 1 Error: Selector shall be polymorphic in SELECT TYPE statement at (1) The first ICE disappeared between r197802 (ICE) and r197969 (errors), and the second one, between r201916 (ICE) and r202111 (errors). Is this PR fixed or not?
[Bug rtl-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #12 from Eric Botcazou ---
This also happens for regular objects on stack, i.e. with a MEM_EXPR:
int a;
int
main (void)
{
char e[3] = { 0, 0, 0 }, f = 0;
if (a == 131072)
f = e[a];
return f;
}
But I think that using MEM_OFFSET would be too conservative as well, for
example if the MEM_EXPR is a structure with a flexible array member. So I
think that we should go for something based on the real offset from SFP/HPF/SP
and the value of get_frame_size plus some bias, even if there might be a gap
with the actual end of the frame, that doesn't really matter.
[Bug ada/60620] New: missing gnattools dependency causes highly parallel build failure with --disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60620
Bug ID: 60620
Summary: missing gnattools dependency causes highly parallel
build failure with --disable-bootstrap
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: gnugcc at marino dot st
GCC 4.9.0 has been brought into FreeBSD ports (lang/gcc-aux) which supports 4
platforms: i386-FreeBSD, i386-DragonFly, x86_64-FreeBSD, and x86-64-DragonFly.
On machines with low -j inputs (say -j4) it would build fine, but on powerful
machines with like -j8 or greater, we'd seen a clean jail (no base compiler lib
in path) build break on gnattools such as this:
checking for scalbnl... ../../xg++ -B../../
-B../../../x86_64-aux-freebsd10.0/libstdc++-v3/src/.libs
-B../../../x86_64-aux-freebsd10.0/libstdc++-v3/libsupc++/.libs
-L../../../x86_64-aux-freebsd10.0/libstdc++-v3/src/.libs
-L../../../x86_64-aux-freebsd10.0/libstdc++-v3/libsupc++/.libs
-static-libstdc++ -static-libgcc -I- -I../rts -I.
-I/work/a/ports/lang/gcc-aux/work/gcc-4.9-20140316/gcc/ada -static-libstdc++
-static-libgcc -DIN_GCC -g -O2 -W -Wall -o ../../gnatlink b_gnatl.o
gnatlink.o a-except.o ali.o alloc.o butil.o casing.o csets.o debug.o fmap.o
fname.o gnatvsn.o hostparm.o indepsw.o interfac.o i-c.o i-cstrin.o namet.o
opt.o osint.o output.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
sdefault.o snames.o stylesw.o switch.o system.o table.o targparm.o tree_io.o
types.o validsw.o widechar.o ../link.o ../targext.o ../../ggc-none.o
../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a ../../../intl/libintl.a
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a
yes
checking for sinf... /usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
gmake[5]: *** [../../gnatlink] Error 1
gmake[5]: *** Waiting for unfinished jobs
It seems this doesn't happen with a full bootstrap. For reference, this is a
typical configuration:
/work/a/ports/lang/gcc-aux/work/gcc-4.9-20140316/configure
--enable-languages=c\ c++\ ada\ fortran\ objc --build=x86_64-aux-freebsd10.0
--prefix=/usr/local/gcc-aux --with-system-zlib --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --enable-shared
--enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp
--enable-libquadmath --enable-nls --disable-bootstrap
It appears the linking using g++ is intentional as -static-libstdc++ is passed,
so that means that libstdc++ is required to build gnattools but that dependency
is not documented. The following patches solved the parallel build problems
with --disable-bootstrap that we were seeing:
--- Makefile.def.orig2013-10-29 13:37:47.0 -0500
+++ Makefile.def
@@ -336,6 +336,7 @@ dependencies = { module=all-libcpp; on=a
dependencies = { module=all-fixincludes; on=all-libiberty; };
dependencies = { module=all-gnattools; on=all-target-libada; };
+dependencies = { module=all-gnattools; on=all-target-libstdc++-v3; };
dependencies = { module=all-lto-plugin; on=all-libiberty; };
--- Makefile.in.orig2014-03-07 07:58:27.0 -0500
+++ Makefile.in
@@ -46730,6 +46730,7 @@ all-stageprofile-libcpp: maybe-all-stage
all-stagefeedback-libcpp: maybe-all-stagefeedback-intl
all-fixincludes: maybe-all-libiberty
all-gnattools: maybe-all-target-libada
+all-gnattools: maybe-all-target-libstdc++-v3
all-lto-plugin: maybe-all-libiberty
all-stage1-lto-plugin: maybe-all-stage1-libiberty
It should be a simple matter to confirm that libstdc++ is indeed required for
gnattools and that it's not listed as a dependency. It is also possible that
gcc 4.8.x is affected by this, but I cannot say as I have never tried to build
that version, nor do I know if libstdc++ is required for gnattools there.
[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 --- Comment #5 from lucdanton at free dot fr --- (In reply to Martin Jambor from comment #2) > Well, this is ICE on code with undefined behavior. Function test > calls itself with a parameter which is a reference to an object of > type child2 and then static_casts it to a reference to child1. These > are non-PODs, neither of these types is an ancestor of the other and > thus the use of static_cast is not allowed by the C++ standard. > […] I must apologise for the peculiar testcase I produced. I normally try to write a sensible program or fragment, but in this case I couldn’t figure out where the problematic behaviour was. In the end I resigned myself to (almost mechanically) discard bits and bits of the original TU until I was left with those things that triggered the ICE and nothing else. (I can’t help but notice that if the testcase is made a complete program by e.g. adding an empty main then strictly speaking there is no UB as control flow never reaches the invalid cast — with the ICE still happening.) For the record, and as best as I can tell, the original code was carefully performing the downcasts inside a (type)case, with no overlap or fallthrough. And if I do apply the patch you supplied, GCC does compile the library without issue.
[Bug middle-end/60429] [4.7 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #29 from Mikael Pettersson --- Richard, your 4.8 backport performs the same call twice in a row on lines 3017 and 3018 in tree-ssa-structalias.c; is that really intentional? + /* We have to include all fields that overlap the current + field shifted by rhsoffset. And we include at least + the last or the first field of the variable to represent + reachability of off-bound addresses, in particular &object + 1, + conservatively correct. */ + temp = first_or_preceding_vi_for_offset (curr, offset); + temp = first_or_preceding_vi_for_offset (curr, offset);
[Bug target/60607] -march=native command line option handling breaks LTO option machinery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607
--- Comment #2 from Markus Trippelsdorf ---
Variation of the problem without -march=native:
markus@x4 tmp % cat foo.ii
markus@x4 tmp % cat bar.ii
typedef int __m128i __attribute__ ((__vector_size__ (16)));
__m128i a, b, c;
void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
markus@x4 tmp % cat main.ii
void dequant_scaling();
int main ()
{
dequant_scaling();
}
markus@x4 tmp % g++ -flto -fPIC -march=amdfam10 -O2 -c foo.ii
markus@x4 tmp % g++ -flto -fPIC -march=amdfam10 -O2 -msse4.1 -c bar.ii
markus@x4 tmp % g++ -flto -march=native -O2 -shared foo.o bar.o
markus@x4 tmp % ar cr test.a foo.o bar.o
markus@x4 tmp % g++ -march=amdfam10 -O2 main.ii test.a
bar.ii: In function ‘dequant_scaling’:
bar.ii:3:61: error: ‘__builtin_ia32_pmulld128’ needs isa option -m32 -msse4.1
void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
^
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/g++ returned 1 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug debug/60603] [4.7/4.8 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603 Jakub Jelinek changed: What|Removed |Added Known to work||4.6.0, 4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |.debug_macinfo/.debug_macro |.debug_macinfo/.debug_macro |has wrong line numbers for |has wrong line numbers for |built-in macros |built-in macros Known to fail||4.7.0, 4.8.2 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug debug/60603] [4.7/4.8/4.9 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Mar 22 07:18:38 2014 New Revision: 208763 URL: http://gcc.gnu.org/viewcvs?rev=208763&root=gcc&view=rev Log: PR debug/60603 c-family/ * c-opts.c (c_finish_options): Restore cb_file_change call to . fortran/ * cpp.c (gfc_cpp_init): Restore cb_change_file call to . testsuite/ * gcc.dg/debug/dwarf2/dwarf2-macro2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-macro2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c trunk/gcc/testsuite/ChangeLog
