[Bug ada/15611] Invalid program not detected, RM 3.7(11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15611 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||charlet at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #7 from Arnaud Charlet charlet at gcc dot gnu.org 2011-08-31 07:04:21 UTC --- Closing then: $ gcc -c test_244943.ads test_244943.ads:4:26: discriminants of tagged type cannot have defaults
[Bug middle-end/43513] The stack pointer is adjusted twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43513 --- Comment #9 from vries at gcc dot gnu.org 2011-08-31 07:04:31 UTC --- Author: vries Date: Wed Aug 31 07:04:25 2011 New Revision: 178353 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178353 Log: 2011-08-31 Tom de Vries t...@codesourcery.com PR middle-end/43513 * Makefile.in (tree-ssa-ccp.o): Add $(PARAMS_H) to rule. * tree-ssa-ccp.c (params.h): Include. (fold_builtin_alloca_for_var): New function. (ccp_fold_stmt): Use fold_builtin_alloca_for_var. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-ssa-ccp.c
[Bug middle-end/43513] The stack pointer is adjusted twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43513 --- Comment #10 from vries at gcc dot gnu.org 2011-08-31 07:06:04 UTC --- Author: vries Date: Wed Aug 31 07:05:59 2011 New Revision: 178354 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178354 Log: 2011-08-31 Tom de Vries t...@codesourcery.com PR middle-end/43513 * gcc.dg/pr43513.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43513.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/15798] Bug box in Gigi, code=201, on legal program with tasking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15798 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||charlet at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #7 from Arnaud Charlet charlet at gcc dot gnu.org 2011-08-31 07:05:33 UTC --- Closing then
[Bug c++/50247] New: #pragma pack std::set segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50247
Bug #: 50247
Summary: #pragma pack std::set segfault
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jsl...@gmail.com
Created attachment 25148
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25148
preprocessed file (with 4.6.1)
When using #pragma pack(1) following code triggers a segfault in stl_tree.h.
When not using #pragma pack, there is no segfault.
Simple testcase:
#pragma pack(1)
#include set
class A
{
public:
bool operator ( const A y) const
{
return this-i y.i;
}
int i;
A(int j)
{
this-i = j;
}
};
int main(void)
{
std::setA aSet;
A a(1);
aSet.insert(a);
return 0;
}
compiled with: g++ test.cpp
Code
g++ -v:
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.6.0-3~ppa1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i686 --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.6.1 20110409 (prerelease) (Ubuntu 4.6.0-3~ppa1)
This also occured with g++ 4.5.2 (x86_64) and with g++ 4.5.3 (arm)
g++ 4.5.2 (x86_64):
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--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.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
g++ 4.5.3 (arm):
Using built-in specs.
COLLECT_GCC=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr/bin/arm-unknown-linux-uclibcgnueabi-g++
COLLECT_LTO_WRAPPER=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr/libexec/gcc/arm-unknown-linux-uclibcgnueabi/4.5.3/lto-wrapper
Target: arm-unknown-linux-uclibcgnueabi
Configured with:
/home/jsn/rtx4088git/toolchain_and_rootfs/output/toolchain/gcc-4.5.3/configure
--prefix=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=arm-unknown-linux-uclibcgnueabi --enable-languages=c,c++
--with-sysroot=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr/arm-unknown-linux-uclibcgnueabi/sysroot
--with-build-time-tools=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr/arm-unknown-linux-uclibcgnueabi/bin
--disable-__cxa_atexit --enable-target-optspace --disable-libgomp --with-gnu-ld
--disable-libssp --disable-multilib --disable-tls --enable-shared
--with-gmp=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr
--with-mpfr=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr
--with-mpc=/home/jsn/rtx4088git/toolchain_and_rootfs/output/host/usr
--disable-nls --enable-threads --disable-decimal-float --with-float=soft
--with-abi=aapcs-linux --with-arch=armv5te --with-tune=arm926ej-s
--with-pkgversion='Buildroot 2011.08-rc1-ged13158-dirty'
--with-bugurl=http://bugs.buildroot.net/
Thread model: posix
gcc version 4.5.3 (Buildroot 2011.08-rc1-ged13158-dirty)
[Bug c++/50239] compiled program segfault when -O0 is used to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-31 08:27:43 UTC --- There's no need to repeat the same info you already provided, please provide what you _didn't_ provide, as requested by http://gcc.gnu.org/bugs/#report we need preprocessed source, and preferably a minimal testcase that has been reduced to the smallest example that still shows the problem
[Bug c++/50247] #pragma pack std::set segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50247 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-31 08:32:04 UTC --- That's user error, you of course can't do this, #pragma pack before include of a standard header changes the ABI. You'd need to rebuild everything with the same change, including libstdc++.
[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-08-31 08:40:24 UTC --- Yes, it's the same problem as in pr48765. I don't know how else to fix it either than backport the patch. Do you think it's not safe because it's a big patch that touches a lot of code? Thanks, Ira
[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-31 08:46:46 UTC --- That's up to you to decide, you are the maintainer ;) My comment was just in the light of a longish ChangeLog entry, haven't read the actual changes how risky they are, if there were any follow-ups needed, etc.
[Bug middle-end/43513] The stack pointer is adjusted twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43513 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org Resolution|DUPLICATE |FIXED AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #11 from vries at gcc dot gnu.org 2011-08-31 08:56:42 UTC --- Patch and test-case checked in, marking fixed.
[Bug c++/50248] New: gcc confused, tries to use variadic template to copy itself when it should use default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50248
Bug #: 50248
Summary: gcc confused, tries to use variadic template to copy
itself when it should use default constructor
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com
Created attachment 25149
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25149
far smaller example than the 3 lines where I first encountered the bug
GCC is trying to instantiate the variadic template as if to copy itself, but
the only thing it should be doing is calling the default constructor.
It only happens when it is constexpr and uses rvalue references.
It only happens when it the parent class has a deleted copy constructor that
takes a *nonconst* reference.
4.5.3 compiles it, but that's because it actually ignores the constexpr
keyword.
Known bad: 4.6.0, 4.6.1-4 debian, svn trunk as of 20110804
Workarounds:
1. Don't use rvalue references.
2. Add a fixed parameter before the variadic one.
Error message:
bug.cpp: In constructor 'constexpr earrayElt, max::earray(Elt2 ...) [with
Elt2 = {earrayshort int, 11u}, Elt = short int, unsigned int max = 11u]':
bug.cpp:25:30: instantiated from here
bug.cpp:9:50: error: cannot convert 'earrayshort int, 11u' to 'short int' in
initialization
bug.cpp:9: confused by earlier errors, bailing out
[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-08-31 09:42:18 UTC --- (In reply to comment #3) That's up to you to decide, you are the maintainer ;) Yes, but not the release manager... My comment was just in the light of a longish ChangeLog entry, haven't read the actual changes how risky they are, if there were any follow-ups needed, etc. I don't remember any follow-ups. I think I'll submit a backport patch. Thanks, Ira
[Bug ada/15844] Illegal program not detected, RM 8.3(8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15844 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:13:46 UTC --- confirmed 4.6.1
[Bug ada/15845] Illegal program not detected, circular renames
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15845 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:18:20 UTC --- confirmed 4.6.1
[Bug ada/15846] Illegal program not detected, self renames
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15846 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:20:44 UTC --- confirmed 4.6.1
[Bug c++/50248] [C++0x] tries to use variadic constructor when it should use default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50248 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-31 10:24:07 UTC --- Thanks for not posting an example of 30k lines :) another workaround is to add these constructors: MapSessionData(const MapSessionData) = delete; MapSessionData() = default; The error does not come from failing to use the default constructor, it comes from the implicit-definition of the MapSessionData copy constructor. [class.copy]/8 says: - earray has an implicitly-declared copy-constructor of the form earray(const earray), - MapSessionData has an implicitly-declared copy constructor of the form MapSessionData(MapSessionData) because its base class has a copy-constructor taking a non-const parameter. The implicitly-declared MapSessionData(MapSessionData) copy-ctor should only be implicitly-defined if it is odr-used (p13) so I'm not sure why it is, but that implicit definition attempts to initialize equip_index with a non-const parameter, which selects the variadic template because the earray(const earray) constructor is not viable. (The workaround above prevents the implicit-declaration of the MapSessionData copy-ctor, so it doesn't attempt to use the variadic template.) Jason, is it correct that the copy ctor is implicitly-defined?
[Bug ada/15917] Bug box in Gigi, code=103, on legal program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15917 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #5 from nicolas.boulenguez at free dot fr 2011-08-31 10:25:00 UTC --- +===GNAT BUG DETECTED==+ | 4.6.1 (x86_64-pc-linux-gnu) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:599 | | Error detected at test_70.adb:18:9 |
[Bug ada/16075] Wrong output from legal program, ordered generic parameter association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16075 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:31:24 UTC --- confirmed 4.6.1
[Bug ada/16076] Illegal program not detected, RM 13.14(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16076 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:34:49 UTC --- confirmed 4.6.1
[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 --- Comment #5 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-08-31 10:36:51 UTC --- This problem is not very important. If it's hard to fix this bug, then do not fix it.
[Bug ada/16077] Wrong output from legal program, pragma Import (Ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16077 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 10:39:23 UTC --- confirmed 4.6.1
[Bug ada/16081] Illegal program not detected, ambiguous call to =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16081 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 10:46:43 UTC --- found 4.6.1
[Bug ada/16082] Legal program rejected, expect derived type in instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16082 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:15:38 UTC --- found 4.6.1
[Bug ada/16083] Illegal program not detected, RM 3.9.2(13)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16083 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:25:14 UTC --- found 4.6.1
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #14 from janus at gcc dot gnu.org 2011-08-31 11:28:41 UTC --- (In reply to comment #13) gfortran-4.7 -c module.f90 gfortran-4.7 program.f90 What about gfortran-4.7 program.f90 module.o? AFAIK there is not object in the *.mod files. Of course. If I fail to include all object files in the linking process, I should not be too surprised about linker errors. Sorry about the noise, yesterday just wasn't my day :(
[Bug ada/16084] Illegal program not detected, RM 3.10.2(24)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16084 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:33:46 UTC --- found 4.6.1
[Bug rtl-optimization/50249] New: ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249
Bug #: 50249
Summary: ira marks wrong value for inheriting
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
Using an approved-for-commit middle-end patch for bug 43864, I hit the
following
error in ira:
Before ira, insn 320 defines r588, which is used in identical loads insn 321
and
insn 329.
10.cc.188r.asmcons:
...
(insn 320 318 321 20 (set (reg/f:SI 588)
(plus:SI (reg/f:SI 166)
(const_int -12))) 5 {*thumb1_addsi3}
(nil))
(insn 321 320 322 20 (set (reg:SI 379)
(mem:SI (reg/f:SI 588))) 177 {*thumb1_movsi_insn}
(nil))
(insn 322 321 326 20 (set (mem/s/f:SI (plus:SI (reg/f:SI 329)
(reg:SI 379)))
(reg/f:SI 170)) 177 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 379)
(nil)))
(insn 326 322 329 20 (set (mem/s/c:SI (plus:SI (reg/f:SI 329)
(const_int 4)))
(reg:SI 338)) 177 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 338)
(nil)))
(insn 329 326 330 20 (set (reg:SI 386)
(mem:SI (reg/f:SI 588) )) 177 {*thumb1_movsi_insn}
(nil))
(insn 330 329 331 20 (set (reg:SI 385)
(plus:SI (reg/f:SI 329)
(reg:SI 386))) 5 {*thumb1_addsi3}
(expr_list:REG_DEAD (reg:SI 386)
(nil)))
...
After ira, r588 is defined by insn 1140, insn 1141 an insn 320 in r10.
It is then copied to r1 by insn 1143, before being used in the first load,
insn 1144. This first load also overwrites r1.
The second load, insn 1146 however uses r1 as if is was still a copy of r10.
10.cc.191r.ira:
...
(insn 1140 1139 1141 20 (set (reg/f:SI 10 sl [588])
(reg:SI 1 r1)) 177 {*thumb1_movsi_insn}
(nil))
(insn 1141 1140 320 20 (set (reg:SI 2 r2)
(const_int -12)) 177 {*thumb1_movsi_insn}
(nil))
(insn 320 1141 321 20 (set (reg/f:SI 10 sl [588])
(plus:SI (reg/f:SI 10 sl [588])
(reg:SI 2 r2))) 5 {*thumb1_addsi3}
(nil))
(note 321 320 1145 20 NOTE_INSN_DELETED)
(insn 1145 321 1142 20 (set (reg:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 12
177 {*thumb1_movsi_insn}
(nil))
(insn 1142 1145 1143 20 (set (reg:SI 2 r2)
(plus:SI (reg/f:SI 13 sp)
(const_int 336))) 5 {*thumb1_addsi3}
(nil))
(insn 1143 1142 1144 20 (set (reg:SI 1 r1)
(reg/f:SI 10 sl [588])) 177 {*thumb1_movsi_insn}
(nil))
(insn 1144 1143 322 20 (set (reg:SI 1 r1)
(mem:SI (reg:SI 1 r1)))
177 {*thumb1_movsi_insn}
(nil))
(insn 322 1144 326 20 (set (mem/s/f:SI (plus:SI (reg:SI 2 r2)
(reg:SI 1 r1)))
(reg:SI 0 r0)) 177 {*thumb1_movsi_insn}
(nil))
(insn 326 322 329 20 (set (mem/s/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 340)))
(reg:SI 3 r3 [338])) 177 {*thumb1_movsi_insn}
(nil))
(note 329 326 1146 20 NOTE_INSN_DELETED)
(insn 1146 329 330 20 (set (reg:SI 1 r1)
(mem:SI (reg:SI 1 r1)))
177 {*thumb1_movsi_insn}
(nil))
(insn 330 1146 332 20 (set (reg:SI 0 r0 [385])
(plus:SI (reg:SI 2 r2)
(reg:SI 1 r1))) 5 {*thumb1_addsi3}
(nil))
...
The reloads for insn 322 are visible in the ira dump. Reload 1 is the copy from
r10 to r1. Reload 2 is the first load.
10.cc.191r.ira:
...
Reloads for insn # 322
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 13 sp)
(const_int 336))
LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (plus:SI (reg/f:SI 13 sp)
(const_int 336))
reload_reg_rtx: (reg:SI 2 r2)
Reload 1: reload_in (SI) = (reg/f:SI 10 sl [588])
BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:SI 10 sl [588])
reload_reg_rtx: (reg:SI 1 r1)
Reload 2: reload_in (SI) = (mem:SI (reg/f:SI 10 sl [588]))
LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
reload_in_reg: (reg:SI 379)
reload_reg_rtx: (reg:SI 1 r1)
Reload 3: LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
Reload 4: reload_out (SI) = (mem/s/f:SI (plus:SI (plus:SI (reg/f:SI 13 sp)
(const_int 336))
(reg:SI 379 )))
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/s/f:SI (plus:SI (plus:SI (reg/f:SI 13 sp)
(const_int 336))
(reg:SI 379)))
secondary_out_reload = 3
Reload 5: reload_in (SI) = (reg/f:SI 170)
LO_REGS,
[Bug ada/16094] Illegal program not detected, RM 3.4.1(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16094 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 11:35:36 UTC --- found 4.6.1
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #1 from vries at gcc dot gnu.org 2011-08-31 11:39:32 UTC --- Created attachment 25150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25150 test case testcase reduced from libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc. to reproduce: $ arm-none-linux-gnueabi-g++ -g -O2 ./10.cc -mthumb -S -fdump-rtl-all-all
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #2 from vries at gcc dot gnu.org 2011-08-31 11:40:19 UTC --- Created attachment 25151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25151 dump before ira
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #3 from vries at gcc dot gnu.org 2011-08-31 11:40:47 UTC --- Created attachment 25152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25152 dump of ira
[Bug ada/16095] Illegal program not detected, accessibility levels, RM 3.10.2(28)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16095 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #5 from nicolas.boulenguez at free dot fr 2011-08-31 11:41:26 UTC --- found 4.6.1
[Bug ada/16096] Illegal program not detected, RM 8.5.4(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16096 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:44:02 UTC --- found 4.6.1
[Bug ada/16097] Illegal program not detected, RM 6.3.1(9), RM 8.5.4(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16097 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:47:40 UTC --- found 4.6.1
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #4 from vries at gcc dot gnu.org 2011-08-31 11:52:12 UTC --- Created attachment 25153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25153 compiler patch necessary to trigger the problem Attached patch was used on top of r178259, and build with configure as reported by gcc -v: ... $ ./arm-none-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=./install/bin/arm-none-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/scratch/vries/b5/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/install/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.0/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-checking=yes,rtl --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/install/arm-none-linux-gnueabi/libc --with-gmp=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpfr=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpc=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-ppl=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-libelf=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/obj/host-libs-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/home/vries/local/pr43864.38.all-fsf-mainline-arm-none-linux-gnueabi.cfg/install/arm-none-linux-gnueabi/bin Thread model: posix gcc version 4.7.0 20110829 (experimental) (GCC) ...
[Bug ada/16212] ICE ada/gcc-interface/trans.c:1626 on legal Ada 83 program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16212 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #4 from nicolas.boulenguez at free dot fr 2011-08-31 11:52:16 UTC --- found 4.6.1
[Bug ada/16214] Legal program rejected, nested generic packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16214 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 11:56:54 UTC --- found 4.6.1
[Bug ada/17320] Illegal program not detected, RM 3.9.3(11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17320 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 12:00:54 UTC --- found 4.6.1
[Bug ada/17321] Illegal program not detected, name hidden by use clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17321 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 12:04:17 UTC --- found 4.6.1
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #5 from vries at gcc dot gnu.org 2011-08-31 12:14:12 UTC --- I bisected the failure to r172389, but to me that looks more like a trigger than a cause: ... 2011-04-13 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/48455 * ira-costs.c (find_costs_and_classes): Use i_mem_cost instead of `temp_costs-mem_cost'. ...
[Bug driver/50250] New: Driver documentation on -l does not mention shared libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50250
Bug #: 50250
Summary: Driver documentation on -l does not mention shared
libraries
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: documentation
Severity: minor
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Forwarded from http://bugzilla.novell.com/show_bug.cgi?id=674696
The documentation says
---
@cindex Libraries
@item -l@var{library}
@itemx -l @var{library}
@opindex l
Search the library named @var{library} when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order they
are specified. Thus, @samp{foo.o -lz bar.o} searches library @samp{z}
after file @file{foo.o} but before @file{bar.o}. If @file{bar.o} refers
to functions in @samp{z}, those functions may not be loaded.
The linker searches a standard list of directories for the library,
which is actually a file named @file{lib@var{library}.a}. The linker
then uses this file as if it had been specified precisely by name.
The directories searched include several standard system directories
plus any that you specify with @option{-L}.
Normally the files found this way are library files---archive files
whose members are object files. The linker handles an archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion. The only
difference between using an @option{-l} option and specifying a file name
is that @option{-l} surrounds @var{library} with @samp{lib} and @samp{.a}
and searches several directories.
note how it specifically mentions -lX searches for libX.a. But:
gcc t.c -lX
also finds libX.so which it should not, according to the above documentation.
The documentation should be clarified and refer to whatever used target linker
documentation.
[Bug ada/17954] Legal program rejected, packed array of booleans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17954 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 12:41:28 UTC --- From: Jörgen Tegnér jorgen.teg...@telia.com The compiler message is different with 4.3.2-2. Now it reads test_124.ads:12:36: size for T1_arr_constrained too small, minimum allowed is 256 test_124.ads:22:36: size for T2_arr_constrained too small, minimum allowed is 248 I get the same results with 4.6.1, so I propose to test only one type. package Test_124 is type T is range 1 .. 32; type T_arr_unconstrained is array (T range ) of boolean; type T_arr_constrained is new T_arr_unconstrained (T); pragma pack (T_arr_unconstrained); for T_arr_constrained'size use 32; end Test_124;
[Bug middle-end/50251] New: [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 Bug #: 50251 Summary: [4.7 Regression] Revision 178353 caused many test failures Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: t...@codesourcery.com On Linux/x86, revision 178353: http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01372.html caused: FAIL: gcc.c-torture/execute/20010209-1.c compilation, -O2 -flto (internal compiler error) FAIL: gcc.c-torture/execute/20010209-1.c compilation, -O2 -flto -flto-partition=none (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O2 (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess errors)
[Bug ada/18205] Legal program rejected, RM 13.13.2(14)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18205 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 12:49:48 UTC --- found 4.6.1
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug ada/18221] Illegal program not detected, access to invisible type RM 8.2(9)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18221 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 13:07:28 UTC --- Found 4.6.1. I suggest to provide a body, so that there is no other illegality. package Test_128 is package inner is private type T1; end inner; type T1_ptr is access inner.T1; -- line 9 ERROR: gnat mistakenly accepts end Test_128; package body test_128 is package body inner is type T1 is new Integer; end inner; end Test_128;
[Bug ada/31416] Illegal program not detected, RM 7.3(13), 4.9.1(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31416 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 13:19:46 UTC --- found 4.6.1
[Bug c++/50248] [C++0x] unnecessary instantiation of constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50248 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-31 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|[C++0x] tries to use|[C++0x] unnecessary |variadic constructor when |instantiation of constexpr |it should use default |constructor |constructor | Ever Confirmed|0 |1 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-31 13:29:33 UTC --- The copy constructor isn't being defined, but the compiler is instantiating the constexpr constructor to find out if it is really constexpr, and therefore whether the implicitly-declared copy constructor should be declared constexpr. We decided at Bloomington that we should just consider instantiations of constexpr templates to be constexpr, not instantiate them to check.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #31 from Marc Glisse marc.glisse at normalesup dot org 2011-08-31
13:40:28 UTC ---
(In reply to comment #25)
(In reply to comment #23)
I think you can do it with a alias-declaration in an extern C block:
extern C {
templatetypename T
using func_type = T (*)();
}
extern C void c() { }
templatetypename T
void f( func_typeT p ) { p(); }
int main()
{
f(c);
}
But yes, it's a bit of a hole in the type system that language linkage is
part
of the type but can only be specified in some contexts and can't be deduced
by
templates.
Yes, I thought about the alias, but it doesn't deduce the type. I really don't
think your example works unless you call fthetype(c) as aliases are not
supposed to be deduced.
Sorry for that comment, I was completely wrong because of a gross
misunderstanding of template aliases, your solution is great (as soon as gcc
has template aliases ;-).
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/43df1e789d3b44fe
[Bug ada/18454] Illegal program not detected, RM 10.1.5(4), 8.1(16)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18454 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 14:00:40 UTC --- found 4.6.1
[Bug fortran/50252] New: Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252 Bug #: 50252 Summary: Error message on call x%y (x not declared) can be more informative Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.markus...@gmail.com If you forget to declare a variable with type-bound procedures, say x, and call one of the intended procedures anyway, the message is simply that there was a syntax error. The program: program test123 call bb%print end program test123 results in the following error message: xx.f90:3.11: call x%print 1 Error: Syntax error in CALL statement at (1) This message could be made clearer by pointing out that a variable may not be declared - if the statement contains a %: Error: Syntax error in CALL statement at (1). Possibly a variable has not been declared.
[Bug ada/18765] Illegal program not detected, /= when = is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18765 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 14:30:58 UTC --- found 4.6.1
[Bug ada/40936] Assert_Failure atree.adb:884 on illegal code (mixture of protected object and accept of entry family)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40936 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 14:36:14 UTC --- 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure atree.adb:794
[Bug ada/31417] Illegal program not detected, RM 7.3(13), 4.9.1(1), nonstatic discriminants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31417 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 14:40:29 UTC --- found 4.6.1
[Bug ada/32164] [4.4/4.5/4.6/4.7 Regression] ICE when renaming predefined = and /=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #12 from nicolas.boulenguez at free dot fr 2011-08-31 14:50:51 UTC --- We now have two distinct assertion failures. First version with T1 Eq Neq gives: 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure einfo.adb:904 Error detected at pak1.ads:1:1 Second version with T1 Eq and T2 Eq gives: 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure einfo.adb:910 Error detected at pak2.ads:6:43
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-08-31
Ever Confirmed|0 |1
--- Comment #1 from vries at gcc dot gnu.org 2011-08-31 14:56:24 UTC ---
reproduced first failure:
...
/home/vries/local/i686/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/20010209-1.c:
In function 'main':
/home/vries/local/i686/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/20010209-1.c:21:1:
internal compiler error: in print_reg, at config/i386/i386.c:13309
...
back-trace lto1 at failure:
...
(gdb) bt
#0 0xf7e6b4d4 in exit () from /lib32/libc.so.6
#1 0x08eab8af in diagnostic_action_after_output (context=0x965f240,
diagnostic=0xd0f4) at
/home/vries/local/i686/src/gcc-mainline/gcc/diagnostic.c:243
#2 0x08eac366 in diagnostic_report_diagnostic (context=0x965f240,
diagnostic=0xd0f4) at
/home/vries/local/i686/src/gcc-mainline/gcc/diagnostic.c:546
#3 0x08eac9c8 in internal_error (gmsgid=0x9358ca3 in %s, at %s:%d) at
/home/vries/local/i686/src/gcc-mainline/gcc/diagnostic.c:839
#4 0x08eaca90 in fancy_abort (file=0x91fdb24
/home/vries/local/i686/src/gcc-mainline/gcc/config/i386/i386.c, line=13309,
function=0x9213ccf print_reg)
at /home/vries/local/i686/src/gcc-mainline/gcc/diagnostic.c:893
#5 0x08a2d4ba in print_reg (x=0xf7d4d090, code=0, file=0x9692b68) at
/home/vries/local/i686/src/gcc-mainline/gcc/config/i386/i386.c:13304
#6 0x08a2f44f in ix86_print_operand_address (file=0x9692b68, addr=0xf7e04cb4)
at /home/vries/local/i686/src/gcc-mainline/gcc/config/i386/i386.c:14224
#7 0x083b6a8a in output_address (x=0xf7e04cb4) at
/home/vries/local/i686/src/gcc-mainline/gcc/final.c:3540
#8 0x08a2ecd5 in ix86_print_operand (file=0x9692b68, x=0xf7e04cb4, code=0) at
/home/vries/local/i686/src/gcc-mainline/gcc/config/i386/i386.c:14038
#9 0x083b6a2c in output_operand (x=0xf7e04cc0, code=0) at
/home/vries/local/i686/src/gcc-mainline/gcc/final.c:3524
#10 0x083b6752 in output_asm_insn (templ=0x92d1e13 mov{l}\t{%1, %0|%0, %1},
operands=0x962a4e0) at /home/vries/local/i686/src/gcc-mainline/gcc/final.c:3422
#11 0x083b56e8 in final_scan_insn (insn=0xf7d47f9c, file=0x9692b68,
optimize_p=2, nopeepholes=0, seen=0xd5a0) at
/home/vries/local/i686/src/gcc-mainline/gcc/final.c:2745
#12 0x083b3e39 in final (first=0xf7db4d20, file=0x9692b68, optimize_p=2) at
/home/vries/local/i686/src/gcc-mainline/gcc/final.c:1786
#13 0x083b7b5f in rest_of_handle_final () at
/home/vries/local/i686/src/gcc-mainline/gcc/final.c:4221
#14 0x08611dac in execute_one_pass (pass=0x9528da0) at
/home/vries/local/i686/src/gcc-mainline/gcc/passes.c:2063
#15 0x08611f8d in execute_pass_list (pass=0x9528da0) at
/home/vries/local/i686/src/gcc-mainline/gcc/passes.c:2118
#16 0x08611fb9 in execute_pass_list (pass=0x9529700) at
/home/vries/local/i686/src/gcc-mainline/gcc/passes.c:2119
#17 0x08611fb9 in execute_pass_list (pass=0x95296c0) at
/home/vries/local/i686/src/gcc-mainline/gcc/passes.c:2119
#18 0x087998b1 in tree_rest_of_compilation (fndecl=0xf7df2800) at
/home/vries/local/i686/src/gcc-mainline/gcc/tree-optimize.c:420
#19 0x082b1573 in cgraph_expand_function (node=0xf7d493d8) at
/home/vries/local/i686/src/gcc-mainline/gcc/cgraphunit.c:1797
#20 0x082b1727 in cgraph_expand_all_functions () at
/home/vries/local/i686/src/gcc-mainline/gcc/cgraphunit.c:1856
#21 0x082b1e30 in cgraph_optimize () at
/home/vries/local/i686/src/gcc-mainline/gcc/cgraphunit.c:2126
#22 0x081eec20 in lto_main () at
/home/vries/local/i686/src/gcc-mainline/gcc/lto/lto.c:2803
#23 0x086ff03c in compile_file () at
/home/vries/local/i686/src/gcc-mainline/gcc/toplev.c:548
#24 0x087010bf in do_compile () at
/home/vries/local/i686/src/gcc-mainline/gcc/toplev.c:1886
#25 0x0870123d in toplev_main (argc=18, argv=0x9668ed8) at
/home/vries/local/i686/src/gcc-mainline/gcc/toplev.c:1962
#26 0x081f17ab in main (argc=18, argv=0xd964) at
/home/vries/local/i686/src/gcc-mainline/gcc/main.c:36
...
we're trying to print the following instruction using output template
'mov{l}\t{%1, %0|%0, %1}':
...
(gdb) call debug_rtx (insn)
(insn:TI 76 22 77 3 (set (reg:SI 2 cx [74])
(mem:SI (plus:SI (plus:SI (mult:SI (reg:SI 0 ax [orig:62 ivtmp.5 ]
[62])
(const_int 4 [0x4]))
(reg/f:SI 20 frame))
(const_int -36 [0xffdc])) [2 MEM[symbol: D.2280,
index: ivtmp.5_9, step: 4, offset: 4294967292B]+0 S4 A32]))
/home/vries/local/i686/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/20010209-1.c:9
64 {*movsi_internal}
(nil))
...
The compiler asserts when trying to print '(reg/f:SI 20 frame)' using print_reg
at:
...
13299print_reg (rtx x, int code, FILE *file)
13300{
13301 const char *reg;
13302 bool duplicated = code == 'd'
[Bug libstdc++/50160] vectorbool comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 --- Comment #26 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-31 15:23:56 UTC --- Various processors have an instruction to reverse the bit order in a word (ARMv6T2 and later have RBIT, for example, and C6X has BITR on C64X and above). I think a generic built-in function (variants for different type sizes) with associated generic RTL representation and lowering for processors without such an instruction makes sense.
[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243 --- Comment #2 from congruwer at yahoo dot co.uk 2011-08-31 15:27:52 UTC --- Not in this case. The example is set up such that the vtable is invisible, even if it is emitted. Since no one can access it, it cannot be required. (I have searched through the ABI documentation again, and it doesn't seem to require the presence of unreferenced vtables. And if it did, that would be a logical contradiction.) There is, in principle, an absolute guarantee that the fields of iface's vtable will never get accessed, and that ___cxa_pure_virtual will never get called, or at least not through iface's vtable.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-31 15:27:44 UTC --- On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2011-08-31 04:21:53 UTC --- (In reply to comment #10) On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote: The main issue is mixing input .ctors sections with .init_array sections to generate the single output .init_array section. Not all linkers support it even if they support .init_array section. How should we properly test this? Is it not possible to link (with -r, maybe) objects and examine the output with target objdump to see if .ctors sections are still present? ld -r won't/shouldn't combine different sections. We can use ld to generate executables. How can we check if input .ctors.* and .init_array.* sections are placed in the right order? Arrange for the contents to have appropriate text values you can check for with grep (or if you wish a custom C program to run on the build system to examine ELF structures - only ELF needs to be considered for this, after all, and I think at this point you may even be able to rely on having libiberty already built for the build system, complete with the simple-object-elf code).
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2011-08-31 15:44:02 UTC --- (In reply to comment #12) Arrange for the contents to have appropriate text values you can check for with grep (or if you wish a custom C program to run on the build system to examine ELF structures - only ELF needs to be considered for this, after all, and I think at this point you may even be able to rely on having libiberty already built for the build system, complete with the simple-object-elf code). .init_array section is an array of pointers. How do you grep it?
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 --- Comment #2 from congruwer at yahoo dot co.uk 2011-08-31 15:46:19 UTC --- Sometimes I want to implement an entire method or function in assembler. The main reasons are: 1) I want to thunk to another function c. in a way that is hard to do from C++. 2) The compiler generated horrible code, because of an optimization bug for example. 3) I need to execute a some specific opcodes. For loose functions you can sometimes get away with using a definition in a separate assembler module (although getting the name mangling right is a pain) but for methods this is often impossible since C++ doesn't see the assembler definition of the method (or constructor c.) and that can cause problems. The most recent problem that made me want this was a badly optimised destructor that pulled in a lot of dependencies via the destructor prologue. I really want the destructor in question to be inlined (since it's essentially empty) but that doesn't work when the destructor is defined in a separate file. Trying to use asm() won't work since the problem is in the prologue and the compiler ignores the naked attribute. For now I've deleted it, but that is a cause of potential bugs since a non-existent destructor doesn't have the protected: visibility specifier.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-31 15:46:46 UTC --- On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2011-08-31 15:44:02 UTC --- (In reply to comment #12) Arrange for the contents to have appropriate text values you can check for with grep (or if you wish a custom C program to run on the build system to examine ELF structures - only ELF needs to be considered for this, after all, and I think at this point you may even be able to rely on having libiberty already built for the build system, complete with the simple-object-elf code). .init_array section is an array of pointers. How do you grep it? You arrange for the pointers to be assigned values whose bytes happen to correspond to text (endian-independent text, ideally). Just like using grep to determine target endianness or floating point format.
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-31 16:10:59 UTC --- You can define whole functions in toplevel asms, like: asm (.globl foobar; .type foobar, @function;\n foobar: whatever; ret; .size foobar, . - foobar;\n);
[Bug c/50254] New: gcc-4.5 -fstrict-aliasing -fschedule-insns optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50254 Bug #: 50254 Summary: gcc-4.5 -fstrict-aliasing -fschedule-insns optimization produces wrong code Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vzapols...@gmail.com Created attachment 25154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25154 test code Hello, recently my team found a problem in our code after a gcc compiler update from gcc-4.4 to gcc-4.5. I've extracted the problematic code snippet, you can find it in the attachement. The problem is unveiled, if you try to compile the test with various combinations of base optimization and strict-aliasing and fschedule-insns flags. For instance that's what I get on my amd64/gcc-4.6.0: log $ gcc -O0 test.c -o test ./test $ gcc -O0 -fschedule-insnstest.c -o test ./test $ gcc -O0 -fstrict-aliasingtest.c -o test ./test $ gcc -O0 -fstrict-aliasing-fschedule-insnstest.c -o test ./test Aborted $ gcc -O1 test.c -o test ./test $ gcc -O1 -fschedule-insnstest.c -o test ./test $ gcc -O1 -fstrict-aliasingtest.c -o test ./test Aborted $ gcc -O1 -fstrict-aliasing-fschedule-insnstest.c -o test ./test Aborted $ gcc -O2 test.c -o test ./test Aborted $ gcc -O2 -fno-strict-aliasing test.c -o test ./test $ gcc -O2 -fno-schedule-insns test.c -o test ./test Aborted $ gcc -O2 -fno-strict-aliasing -fno-schedule-insns test.c -o test ./test $ /log The problem described above is reproducible on armv7, i386, amd64 target architectures with gcc-4.5 and gcc-4.6 compilers. The issue might be invalid, but because it hasn't been known with gcc-4.4, I'd greatly appreciate to get some comments from GCC team on it. Thank you in advance.
[Bug c++/26099] support for type traits is not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099 --- Comment #31 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-31 17:11:38 UTC --- __is_convertible_to isn't such a big issue anymore, thanks to Core/1170 (in C++11 SFINAE includes access control, still unimplemented in GCC, though). However, we now need front-end support for the is_trivially_* traits.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2011-08-31 17:17:27 UTC --- Author: jamborm Date: Wed Aug 31 17:17:19 2011 New Revision: 178386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178386 Log: 2011-08-31 Martin Jambor mjam...@suse.cz PR middle-end/49886 * ipa-inline-analysis.c (compute_inline_parameters): Set can_change_signature of noes with typde attributes. * ipa-split.c (split_function): Do not skip any arguments if can_change_signature is set. * testsuite/gcc.c-torture/execute/pr49886.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49886.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug libgcj/50241] Building from the current branch - 178337 fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50241 --- Comment #4 from George R. Goffe grgoffe at yahoo dot com 2011-08-31 17:38:13 UTC --- Andrew, Thank you for your time and the hint. Regards, George...
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #51 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-08-31 17:48:05 UTC --- So, I propose we fix this now and deal with any potential fallout later. Slightly bug pushing, which I'm not terribly fond of, but, better than leaving it sit. The other fix, arguable better, would be to never use a public common for this lto data. I don't understand and know lto well enough to know what to suggest. If things can look at private symbols, maybe make it private. If it doesn't have to be storage, make it an absolute value. Add a target hook to generate it, and then do something special for darwin. Make it a hard define, which is weak. Try one's hand at COMDAT on it. When it comes to shared libraries, having any trace of common could be a deal killer anyway.
[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-08-31 17:55:19 UTC --- I don't have a take on the best way to fix this. With that said, if you like the last patch and it tests out, Ok.
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851 --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-08-31 17:58:49 UTC --- I don't have the regeneration environment for fixincludes, could you post the patch with the regeneration bits in it and ask for approval?
[Bug fortran/50252] [OOP] Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|Error message on call x%y |[OOP] Error message on |(x not declared) can be |call x%y (x not declared) |more informative|can be more informative --- Comment #1 from janus at gcc dot gnu.org 2011-08-31 19:03:39 UTC --- The parsing of call statements happens in gfc_match_call (match.c), so any improvement of the error message will most likely have to happen there.
[Bug fortran/50252] [OOP] Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252
--- Comment #2 from janus at gcc dot gnu.org 2011-08-31 19:31:10 UTC ---
Ok, here is one thing that could be easily done. Preliminary patch, not
regtested. Does this sound like an improvement?
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 178293)
+++ gcc/fortran/match.c (working copy)
@@ -3639,15 +3639,24 @@ done:
}
-/* Match the call of a type-bound procedure, if CALL%var has already been
- matched and var found to be a derived-type variable. */
+/* Match the call of a type-bound procedure, if 'CALL var' has already been
+ matched. */
static match
match_typebound_call (gfc_symtree* varst)
{
gfc_expr* base;
+ gfc_symbol *sym;
match m;
+ sym = varst-n.sym;
+ if (sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
+{
+ gfc_error (Base object '%s' in type-bound procedure call at %C
+is not of derived type, sym-name);
+ return MATCH_ERROR;
+}
+
base = gfc_get_expr ();
base-expr_type = EXPR_VARIABLE;
base-symtree = varst;
@@ -3718,7 +3727,7 @@ gfc_match_call (void)
procedure call. */
if ((sym-attr.flavor != FL_PROCEDURE
|| gfc_is_function_return_value (sym, gfc_current_ns))
- (sym-ts.type == BT_DERIVED || sym-ts.type == BT_CLASS))
+ gfc_peek_char() == '%')
return match_typebound_call (st);
/* If it does not seem to be callable (include functions so that the
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #3 from Zaak zbeekman at gmail dot com 2011-08-31 19:49:20 UTC --- When I pass -E some strange behaviour occurs. First of all the code is preprocessed with the c preprocessor and unless the -o flag is passed the output is written to standard out, so this text will get included in the .d dependency definition files which are to be included in the makefile. One can avoid this issue if one passes -o /dev/null or does something clever with sed. A second side effect of -E is that the module dependencies are no longer included in the output which again renders this useless. After passing through the sed command (as outlined in the GNU Make documentation) the last line of modtypes.d went from: modtypes.o types.mod: modtypes.f90 to modtypes.o: modtypes.f90
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #4 from Zaak zbeekman at gmail dot com 2011-08-31 19:58:41 UTC --- Created attachment 25155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25155 test case files with Makefile The Makefile.alt is configured to pass -E and -o /dev/null when building the dependency lists, while the original Makefile does not. In my opinion, the original Makefile should build any object in the project IF gfortran were bug free.
[Bug preprocessor/44526] libcpp should avoid circular dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526 Zaak zbeekman at gmail dot com changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #2 from Zaak zbeekman at gmail dot com 2011-08-31 20:06:03 UTC --- See also bug #49149: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
[Bug target/50223] AVRGCC - dont clear r26 and r27.....its a (small) waste of CPU cycles.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50223 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-31 20:23:25 UTC --- This is just a missed optimization. Thus, you won't see a fix before gcc 4.7. For gcc 4.7, notice that there are optimized versions of builtins that perform your arithmetic like __builtin_clz/clzl/clzll (count leading zeros) __builtin_ctz/ctzl/ctzll (count trailing zeros) __builtin_ffs/ffsl/ffsll (find first (lowest) set bit) ...
[Bug c++/50255] New: Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 Bug #: 50255 Summary: Linker stumbles over non-grouped text/rodata for a non-virtual thunk Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: stephan.bergmann.second...@googlemail.com The below error has first been discussed at http://gcc.gnu.org/ml/gcc/2011-08/msg00455.html. It can at least be observed when building recent versions of LibreOffice (e.g., revision bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of git://anongit.freedesktop.org/libreoffice/core) on Fedora 15 i386 (i.e., with GCC 4.6.0 20110603 (Red Hat 4.6.0-10)). The problem is that linking together objects via g++ -shared vbarange.o vbasheetobjects.o fails with errors like `.L109' referenced in section `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBasecppu::WeakImplHelper1ooo::vba::XCollection ::Item(com::sun::star::uno::Any const, com::sun::star::uno::Any const)]' of vbasheetobjects.o: defined in discarded section `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual thunk to ScVbaCollectionBasecppu::WeakImplHelper1ooo::vba::XCollection ::Item(com::sun::star::uno::Any const, com::sun::star::uno::Any const)]' of vbasheetobjects.o The two C++ files vbarange.cxx and vbasheetobjects.cxx are compiled with identical g++ command lines, including switches -fPIC -fno-common -pipe -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fexceptions -fno-enforce-eh-specs -Os besides more mundane -D, -I, -M, and -W switches. Both objects include code for the _ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_ function, but there are two things that are odd: First, the code emitted for the two functions is rather different in the two object files, even though both are compiled with identical command line switches. One difference is that In vbasheetobjects.o, the code contains a rodata section (see below) with a number of labels into code that follows, whereas the code in vbarange.o does not contain such a rodata section. Could it be that -Os can cause these differences? (If necessary, I can easily make available the -S output for the relevant code from the two different files.) Second, the directive for the rodata section mentioned above is .section .rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,aG,@progbits,_ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,comdat while the directive for the corresponding text section (split in multiple parts) is .section .text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,axG,@progbits,_ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,comdat Note the difference in the GroupName part of the .section directives, the rodata section using the symbol denoting the plain function instead of the non-virtual thunk. The theory is that the rodata and text sections should belong to a single group, so that the linker would either keep or remove them together. What apparently happens instead is that the linker uses the text section from vbarange.o, drops the corresponding text section from vbasheetobjects.o, and then stumbles over the left-over rodata section. (Manually adapting the GroupName of the rodata section directive to match the text section makes the link succeed.) The problem has been worked around for now in LibreOffice by compiling vbasheetobjects.o without -Os (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=148e0ccb50ce419e18e452eb7ccfe03cb4881634, i.e., that change must be reverted before the problem can be observed in the code revision mentioned at the beginning), which makes the problem go aways rather by chance.
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org 2011-08-31 20:47:21 UTC --- (In reply to comment #4) Created attachment 25155 [details] test case files with Makefile The Makefile.alt is configured to pass -E and -o /dev/null when building the dependency lists, while the original Makefile does not. In my opinion, the original Makefile should build any object in the project IF gfortran were bug free. gfortran works just fine with a properly written Makefile. Your Makefile gives me troutmask:sgk[213] make Makefile, line 14: Could not find make: fatal errors encountered -- cannot continue
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-31 21:03:36 UTC --- GCC 4.6.0 20110603 (Red Hat 4.6.0-10)). Does it happen with non RedHat version of the compiler meaning non modified version of GCC? Really you should have reported this first to redhat as they have some modifications to their compiler that might have caused this issue.
[Bug other/49533] [4.7 regression] Revision 174989 (ipa-inline-transform.c) regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-31 21:05:14 UTC --- has this been fixed?
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-31 21:06:43 UTC --- This sounds like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 but without a testcase it is hard to say if it was really on the 4.6 branch or only with RedHat's compiler.
[Bug ada/17953] Illegal program not detected, RM 3.9.2(9)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17953 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 21:47:10 UTC --- found 4.6.1 gnat reports an error when one is commented, but fails to report both.
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #6 from Zaak zbeekman at gmail dot com 2011-08-31 22:01:06 UTC --- I ma not saying gfortran is entirely broken, i'm merely claiming that there is a bug in the dependency resolution feature. Please see GNU Make documentation here for more information about Generating Prerequisites Automatically: http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites There is nothing wrong with my makefile. GNU make looks for rules to build any included makefiles and builds and updates them before running the rest of the makefile. It is this very step that gives me problems too, but because it requires the presence of types.mod before it can run the rule to make modutils.d and myprog.d. The rule to make these files uses gfortran's dependency resolution features which is where the problem is. The following step is what is causing the failure: gccbug $ gfortran -M -cpp modutils.f90 | sed '1 s/^/modutils.d /' modutils.d This is perfectly reasonable thing to want to do and produces the following output: modutils.f90:2.11: USE types 1 Fatal Error: Can't open module file 'types.mod' for reading at (1): No such file or directory The whole point, again, is that we should not need the binary .mod files to accomplish dependency resolution because these .mod files have dependencies which must be resolved in order to create them. The source code file should be parsed for binary objects (.o and .mod) which it produces and which it depends on. The parsing of these source codes and the extraction of this information should not require dependencies and should be order agnostic. I hope you are less confused now.
[Bug ada/18453] Legal instantiation rejected; illegal instantiation accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18453 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-31 22:15:25 UTC --- found 4.6.1
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #7 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-31 22:17:48 UTC --- On Wed, Aug 31, 2011 at 10:01:06PM +, zbeekman at gmail dot com wrote: I hope you are less confused now. I'm not confused. I do, however, use the grey matter between my ears to write my Makefiles. gfortran requires that the *.mod are present to parse your code. Sorry if you cannot deal with that fact.
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #8 from nicolas.boulenguez at free dot fr 2011-08-31 22:22:13 UTC --- found 4.6.1
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #8 from Zaak zbeekman at gmail dot com 2011-08-31 22:27:40 UTC --- (In reply to comment #7) On Wed, Aug 31, 2011 at 10:01:06PM +, zbeekman at gmail dot com wrote: I hope you are less confused now. I'm not confused. I do, however, use the grey matter between my ears to write my Makefiles. gfortran requires that the *.mod are present to parse your code. Sorry if you cannot deal with that fact. I didn't mean any insult, I am not trying to troll or start a flame war. I'm sorry if I offended you in any way. I would appreciate you telling me why you think my makefile is wrong rather than just insulting me. Did you read the link to the GNUmake manpage? Did you try executing the command outside of the makefile? The whole point of having dependency generation capabilities is to do EXACTLY what I'm trying to do. The .mod files are the difficulty resolving Fortran dependencies and I don't see what the use of a tool to resolve dependencies is, if you need to already have those dependencies resolved apriori to use the tool. If you can show me how to write a makefile with pattern rules that will automatically resolve dependencies and uses only brief, terse, pattern rules you will forever be my hero. How would you write a makefile to automatically build fortran codes, and resolve their dependencies without explicitly hand coding the dependencies?
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #9 from Zaak zbeekman at gmail dot com 2011-08-31 22:34:46 UTC --- Additionally, if my entire premise is wrong what do you anticipate the use of the -M flag will be for? It's not hard to figure out that .o files depend on the .f90 files with the same name. I don't need a tool to do that for me, so how do you envision -M being used? Not the way listed on the GNUmake online documentation?
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-31 22:45:41 UTC --- On Wed, Aug 31, 2011 at 10:27:40PM +, zbeekman at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #8 from Zaak zbeekman at gmail dot com 2011-08-31 22:27:40 UTC --- (In reply to comment #7) On Wed, Aug 31, 2011 at 10:01:06PM +, zbeekman at gmail dot com wrote: I hope you are less confused now. I'm not confused. I do, however, use the grey matter between my ears to write my Makefiles. gfortran requires that the *.mod are present to parse your code. Sorry if you cannot deal with that fact. I didn't mean any insult, I am not trying to troll or start a flame war. I'm sorry if I offended you in any way. I would appreciate you telling me why you think my makefile is wrong rather than just insulting me. Did you read the link to the GNUmake manpage? Did you try executing the command outside of the makefile? Yes, I scanned the GNU Make info file. I can find no information in that file concerning Fortran modules. I also scanned the GNU Fortran info file. I can find no mention of using -M to build the dependence for Fortran modules. In fact, -M does not appear anywhere in the GNU Fortran info file. So, one needs to peer into the GNU GCC info file. `-M' Instead of outputting the result of preprocessing, output a rule suitable for `make' describing the dependencies of the main source file. The preprocessor outputs one `make' rule containing the object file name for that source file, a colon, and the names of all the included files, including those coming from `-include' or `-imacros' command line options. Hmmm, no mention of a Fortran 'USE' statement. A 'USE' statement is a different beast than an 'INCLUDE' statement. How would you write a makefile to automatically build fortran codes, and resolve their dependencies without explicitly hand coding the dependencies? Well, as I write the Makefile, I automatically write the correct dependency. I do not depend on an inadequate tool to do the work for me. If you absolutely must have a tool, google makedepf90. PS: *.mod files are binary files.
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #11 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-31 23:05:10 UTC --- On Wed, Aug 31, 2011 at 10:34:46PM +, zbeekman at gmail dot com wrote: Additionally, if my entire premise is wrong what do you anticipate the use of the -M flag will be for? It's not hard to figure out that .o files depend on the .f90 files with the same name. I don't need a tool to do that for me, so how do you envision -M being used? Not the way listed on the GNUmake online documentation? Given that I consider the -M option to be total irrelevant for gfortran, I anticipate that the -M option is useless. In fact there are a boat load of options listed in the GCC info file, which are irrelevant for gfortran. Many of these options are historical baggage from when GCC was simply gcc (ie., a C compiler). Can you show me a specific passage in the GNU Make documentation that states -M can be used to generate dependencies for Fortran USE statements without the actual *.mod being present? What to you expect the -M option to do with program foo use omp_lib use iso_c_binding end program
[Bug c/50256] New: AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256
Bug #: 50256
Summary: AVR GCC - several unnecessary register moves
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nickpar...@eaton.com
Hi,
AVR GCC seems to generate inefficent code. Function below multiplies two
unsigned 24-bit max values, then effectively shifts right by 24 shifts.
uint32_t MulU3U3S3(uint32_t a_u3, uint32_t b_u3)
{
uint32_t answer;
asm volatile
(
push r0 \n\t
push r1 \n\t
clr r20 \n\t // zero register
// 0 byte shifts
mul %A1,%A2 \n\t // a1a2
mov r2,r0\n\t
mov r3,r1\n\t
// 1 byte shifts
mul %A1,%B2 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r20 \n\t
mul %A2,%B1 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r20 \n\t
// 2 byte shifts
mul %A1,%C2 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
mul %A2,%C1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
mul %B2,%B1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
// 3 byte shifts
mul %B1,%C2 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r20 \n\t
mul %B2,%C1 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r20 \n\t
// 4 byte shifts
mul %C2,%C1 \n\t
add r6,r0\n\t
adc r7,r1\n\t
mov %A0,r5 \n\t
mov %B0,r6 \n\t
mov %C0,r7 \n\t
clr %D0 \n\t
pop r1\n\t
pop r0\n\t
: =r (answer)
: r (a_u3), r (b_u3)
: r0,r1,r2,r3,r4,r5,r6,r7,r20
);
return (answer);
}
;
Calling code
(note moves after function..why cant function leave answer in place?)
;
878 040c 6CE5 ldi r22,lo8(167772)
879 040e 7FE8 ldi r23,hi8(167772)
880 0410 82E0 ldi r24,hlo8(167772)
881 0412 90E0 ldi r25,hhi8(167772)
882 0414 20EA ldi r18,lo8(10)
883 0416 36E8 ldi r19,hi8(10)
884 0418 41E0 ldi r20,hlo8(10)
885 041a 50E0 ldi r21,hhi8(10)
886 041c 0E94 call MulU3U3S3
887 0420 7B01 movw r14,r22
888 0422 8C01 movw r16,r24
;
Called code is below. Note that
- one argument is unnecessarily moved to a new location
- at end, result is unnecessarily moved to a new location
also this code is unnecessary too
283 010e 8901 movw r16,r18
284 0110 9A01 movw r18,r20
;
263.global MulU3U3S3
265MulU3U3S3:
266.LFB8:
267.LM19:
268.LVL22:
269 00f6 2F92 push r2
270 00f8 3F92 push r3
271 00fa 4F92 push r4
272 00fc 5F92 push r5
273 00fe 6F92 push r6
274 0100 7F92 push r7
275 0102 CF92 push r12
276 0104 DF92 push r13
277 0106 EF92 push r14
278 0108 FF92 push r15
279 010a 0F93 push r16
280 010c 1F93 push r17
281/* prologue: function */
282/* frame size = 0 */
283 010e 8901 movw r16,r18
284 0110 9A01 movw r18,r20
285.LM20:
286 0112 6801 movw r12,r16
287 0114 7901 movw r14,r18
288/* #APP */
289 ; 326 maths_mul.c 1
290 0116 0F92 push r0
291 0118 1F92 push r1
292 011a 4427 clr r20
293 011c 6C9D mul r22,r12
294 011e 202C mov r2,r0
295 0120 312C mov r3,r1
296 0122 6D9D mul r22,r13
297 0124 300C add r3,r0
[Bug ada/37245] GDB reports No definition of var1 in current context. for an existing variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #3 from nicolas.boulenguez at free dot fr 2011-08-31 23:59:48 UTC --- Linux 3.0.0-1-amd64 x86_64 gcc 4.6.1 (-5 in debian) and gdb 7.2 (-debian) gdb reports the correct answer $1 = 42
[Bug ada/40986] [4.4 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #6 from nicolas.boulenguez at free dot fr 2011-09-01 00:29:34 UTC --- 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:384
[Bug ada/37245] GDB reports No definition of var1 in current context. for an existing variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245 --- Comment #4 from Timo Lindfors timo.lindfors at iki dot fi 2011-09-01 00:31:16 UTC --- The bug still occurs for me on debian testing: lindi2:~/tmp$ gnatmake -ggdb3 -O0 gdb_bug_2 gcc-4.4 -c -ggdb3 -O0 gdb_bug_2.adb gdb_bug_2.adb:25:07: warning: variable gs is read but never assigned gnatbind -x gdb_bug_2.ali gnatlink gdb_bug_2.ali -ggdb3 lindi2:~/tmp$ gdb ./gdb_bug_2 GNU gdb (GDB) 7.2-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/lindi/tmp/gdb_bug_2...done. (gdb) break breakpoint Breakpoint 1 at 0x401322: file gdb_bug_2.adb, line 16. (gdb) run Starting program: /home/lindi/tmp/gdb_bug_2 Breakpoint 1, gdb_bug_2.fitg5.breakpoint () at gdb_bug_2.adb:16 16 end Breakpoint; (gdb) print var1 No definition of var1 in current context. (gdb) print var2 $1 = 43 (gdb) quit A debugging session is active. Inferior 1 [process 11766] will be killed. Quit anyway? (y or n) y lindi2:~/tmp$ dpkg-query -W gdb gdb7.2-1 lindi2:~/tmp$ dpkg-query -W gcc gcc4:4.6.1-2 lindi2:~/tmp$ cat /proc/version Linux version 3.0.0-1-amd64 (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-4) ) #1 SMP Sun Jul 24 02:24:44 UTC 2011 lindi2:~/tmp$ md5sum gdb_bug_2.adb 58638c361f25465b7a6288d0a69c7964 gdb_bug_2.adb and unstable: (sid)lindi1:~/tmp$ gnatmake -ggdb3 -O0 gdb_bug_2 gcc-4.4 -c -ggdb3 -O0 gdb_bug_2.adb gdb_bug_2.adb:25:07: warning: variable gs is read but never assigned gnatbind -x gdb_bug_2.ali gnatlink gdb_bug_2.ali -ggdb3 (sid)lindi1:~/tmp$ gdb ./gdb_bug_2 GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/lindi/tmp/gdb_bug_2...done. (gdb) break breakpoint Breakpoint 1 at 0x401322: file gdb_bug_2.adb, line 16. (gdb) run Starting program: /home/lindi/tmp/gdb_bug_2 Breakpoint 1, gdb_bug_2.fitg5.breakpoint () at gdb_bug_2.adb:16 16 end Breakpoint; (gdb) print var1 No definition of var1 in current context. (gdb) print var2 $1 = 43 (gdb) quit A debugging session is active. Inferior 1 [process 16208] will be killed. Quit anyway? (y or n) y (sid)lindi1:~/tmp$ dpkg-query -W gdb gdb7.3-1 (sid)lindi1:~/tmp$ dpkg-query -W gcc gcc4:4.6.1-2 (sid)lindi1:~/tmp$ cat /proc/version Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011 (the unstable one is in a chroot so it is running older kernel in case you wonder.)
[Bug ada/47818] Pragma Assert is rejected with No_Implementation_Pragmas restriction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47818 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #1 from nicolas.boulenguez at free dot fr 2011-09-01 00:41:36 UTC --- found 4.4.5 (by eu...@debian.org) found 4.6.1 (by me)
[Bug libstdc++/50257] New: unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 Bug #: 50257 Summary: unordered_map slow initialization due to huge __prime_list Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jus...@fathomdb.com The constructor for std::unordered_map calls _Prime_rehash_policy::_M_next_bkt to determine the initial size of the hashtable. That method computes the size by looking for the next largest number in a large list of primes (in src/hashtable-aux.cc), which it does using lower_bound. However, this list is very big - I counted it as 310 elements of 8 bytes each on a 64 bit machine, or ~ 2.4KB, accessed in a way (lower_bound) that probably causes lots of cache misses. This lower_bound call comes up as a performance hotspot on my profiles. I think that: 1) the initial granularity is probably overkill. The inital entries are: 2ul, 3ul, 5ul, 7ul, 11ul, 13ul, 17ul, 19ul, 23ul, 29ul, 31ul, 37ul, 41ul, 43ul, 47ul, 53ul, 59ul, 61ul, 67ul, 71ul, 73ul, 79ul, 83ul, 89ul, 97ul, 103ul, 109ul, 113ul, 127ul, 137ul, 139ul, 149ul, 157ul, 167ul, 179ul, 193ul, 199ul, 211ul, 227ul, 241ul, 257ul,... Overall performance would probably be better/comparable with e.g. 11ul, 31ul, 127ul, 241ul. 2) we should special-case the first values, or (at the very least) the value when size is specified in the unordered_map constructor (I think that's 10). I also found this prime list, which looks a lot more reasonable in terms of the density: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01293.html One of the problems is that this list of primes serves three purposes: 1) Initial allocation when no size is specified (for which it is slow) 2) Initial allocation when the user is specifying the size (when we probably want a size as close as possible to the target number) 3) Resizing (when again we want a size as close as possible to the size we've computed) I think that this is probably a good list for purpose #2 and #3, but it is pretty painful for #1. Unfortunately #1 is the probably the most common use case, I would think. An alternative fix would be to have two different _Prime_rehash_policy strategies: one for people that know the size of their hashtable, and one for people that just want sensible defaults. I don't think _Prime_rehash_policy is a good match for the second group, and I suspect the second group is the majority. Is this the right place to raise this, or would the mailing list be better?
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #12 from Zaak zbeekman at gmail dot com 2011-09-01 01:14:40 UTC --- Can you show me a specific passage in the GNU Make documentation that states -M can be used to generate dependencies for Fortran USE statements without the actual *.mod being present? Bullet number 7 in the what's new in gfortran section for the current stable release, 4.6.0: http://gcc.gnu.org/wiki/GFortran#GCC4.6 ' Support the generation of Makefile dependencies via the `-M...` flags of GCC; you may need to specify additionally the -cpp option. The dependencies take modules, Fortran's include, and CPP's #include into account. Note: Using -M for the module path is no longer supported, use -J instead.' It seems that this is a new feature and the documentation lags the implementation. Being a new feature I thought it was important to report what appears to me to be an important new bug (if I am interpreting the above statement correctly). Note also that Intel has recently added this capability to their Fortran compiler and they too have (different) bugs.
[Bug ada/37245] GDB reports No definition of var1 in current context. for an existing variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245 --- Comment #5 from nicolas.boulenguez at free dot fr 2011-09-01 01:15:04 UTC --- During the Debian transition, the default gnat (4.4.6) uses its own gcc instead of the default gcc (4.6.1), as you can see in line 2 of your log. Summary of our results so far: 4.1.2 reports 1 4.1.3 ok 4.2.3 ok 4.3.1 no definition 4.4.6 no definition 4.6.1 ok
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #13 from Zaak zbeekman at gmail dot com 2011-09-01 01:27:46 UTC --- As for intrinsic F2003 modules, like ISO_C_BINDING, ISO_FORTRAN_ENV, etc. I would expect the compiler to be able to handle this appropriately, i.e. not require the presence of a iso_c_binding module in the build directory. Modules which are provided as compiler extensions to the Fortran standard should also be handled appropriately. My preference would be to exclude such intrinsic and compiler extension modules from the dependency list, but if a .mod file is installed with the compiler, the dependency could be given with a full path to its location. I can't think of an occasion when you would need a path to these intrinsic/extension modules, unless, perhaps, the tool were used while developing the compiler itself. Also, every time I read 'The dependencies take modules, Fortran's include, and CPP's #include into account.' I can't help but think that the creators of this feature were trying to make a useful tool which could handle Fortran specific, especially module, dependency resolution.
