Re: arm-elf float-abi defaults...
On Tue, 2010-05-11 at 17:40 -0400, DJ Delorie wrote:
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it just work but it seems to me it would be better to have the
defaults match, although I'm not sure how to enforce that. Comments?
Suggestions?
Index: gcc/config/arm/elf.h
===
RCS file: gcc/config/arm/elf.h,v
--- gcc/config/arm/elf.h
+++ gcc/config/arm/elf.h
@@ -41,7 +41,13 @@
#endif
#ifndef SUBTARGET_EXTRA_ASM_SPEC
-#define SUBTARGET_EXTRA_ASM_SPEC
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_SOFT
+#define SUBTARGET_EXTRA_ASM_SPEC \
+ %{!msoft-float:%{!mhard-float:%{!mfloat-abi=*:-mfloat-abi=soft}}}
+#else
+#define SUBTARGET_EXTRA_ASM_SPEC \
+ %{!msoft-float:%{!mhard-float:%{!mfloat-abi=*:-mfloat-abi=hard}}}
+#endif
#endif
#ifndef SUBTARGET_ASM_FLOAT_SPEC
Sorry for the delay replying, I've been travelling.
The above is probably technically correct, but it has one major problem,
IIRC: it breaks backwards compatibility with existing objects that are
incorrectly labelled by default -- ie probably most of them, for most
users. Also note that there is no way for a user to force the linker to
ignore this problem, so changing it would effectively force all old
object files to be re-compiled -- something that may well not be
possible.
Given that arm-elf is on the verge of being deprecated, I'm not
convinced this is a good idea.
R.
Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549
On 05/14/2010 03:40 PM, Richard Guenther wrote:
On Fri, May 14, 2010 at 3:34 PM, Toon Moenet...@moene.org wrote:
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code ends up in libraries - .a files - so I
have to, to make -flto -fwhole-program be meaningful).
Is it a problem with COMMON ? Those typically have umpteen definitions,
which all have to match ...
I decided to change the following in lto-symtab.c to help me pinpoint this
culprit:
Index: lto-symtab.c
===
--- lto-symtab.c(revision 159389)
+++ lto-symtab.c(working copy)
@@ -603,8 +603,15 @@
/* Assert it's the only one. */
if (prevailing)
for (e = prevailing-next; e; e = e-next)
- gcc_assert (e-resolution != LDPR_PREVAILING_DEF_IRONLY
- e-resolution != LDPR_PREVAILING_DEF);
+ {
+ if (!(e-resolution != LDPR_PREVAILING_DEF_IRONLY
+ e-resolution != LDPR_PREVAILING_DEF))
+{
+ debug_tree(prevailing-decl);
+ debug_tree(e-decl);
+ gcc_assert(0);
+}
+ }
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
That resulted in the following messages in my compile log:
function_decl 0x2b9d3a4af900 convect_satmixratio
typefunction_type 0x2b9d3a471000
typevoid_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_thispointer_type 0x2b9d3548ddc8
QI
sizeinteger_cst 0x2b9d3547e758 constant 8
unit sizeinteger_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 7712 col 0 align 8
function_decl 0x2b9d3a4af200 convect_satmixratio
typefunction_type 0x2b9d3a471000
typevoid_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_thispointer_type 0x2b9d3548ddc8
QI
sizeinteger_cst 0x2b9d3547e758 constant 8
unit sizeinteger_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 6525 col 0 align 8
lto1: internal compiler error: in lto_symtab_merge_decls_1, at
lto-symtab.c:612
bkconv.f90:7712:
7711 !
7712CALL CONVECT_SATMIXRATIO( KLON, ZWORK1, ZTELCL, ZWORK3, ZLV,
ZLS, ZCPH )
bkfconv.f90:6525:
6524 !
6525 CALL CONVECT_SATMIXRATIO( KLON, ZPLCL, ZTLCL, ZWORK1, ZLV,
ZWORK2, ZCPH )
The only thing I can see is that CONVECT_SATMIXRATIO is called from two
different routines in one file (bkfconv.f90:6260 CONVECT_TRIGGER_SHAL and
bkfconv.f90:7258 CONVECT_CLOSURE_SHAL)
Any suggestions how I can further chase this down ? Are the arguments to
the subroutine an issue (kind, array size, etc.) ?
No, the lto-plugin or gold provides you with broken symbol resolution.
Try 1) update gold, 2) file a bugreport and CC Ian and Cary.
The gold is relatively new (5/6/10), so I did 2 - it's PR lto/44149.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #16 from a14331990 at hotmail dot com 2010-05-15 06:01 --- (In reply to comment #8) I think this is a bug the MingW maintainers should handle. While I understand Andrew's position, it seems to me that this is nevertheless a definite regression from the user's perspective. W. Yes, I think this is mostly a mingw bug, but I think developers of cygwin, a very similar project had already resolved this issue, they had enabled auto-import by default in ld, please follow this post [PATCH] Silence ld auto-import warnings for pe-i386. http://sourceware.org/ml/binutils/2009-02/msg00341.html for details. With auto-import enabled by default in ld, there is no need to emit exported inline functions in gcc code. See my workaround here: FYI: GCC 4.5.0 on Mingw.org http://forums.codeblocks.org/index.php/topic,12183.msg85066.html#msg85066 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug debug/44112] [4.6 regression] Revision 159354 causes Fortran test failures
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-15 06:01 --- Subject: Bug 44112 Author: jakub Date: Sat May 15 06:01:20 2010 New Revision: 159429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159429 Log: PR debug/44112 * dwarf2out.c (resolve_one_addr): Check TREE_ASM_WRITTEN for all SYMBOL_REF_DECLs. * gcc.dg/debug/dwarf2/const-1.c: Remove. * g++.dg/debug/dwarf2/const1.C: Remove. Removed: trunk/gcc/testsuite/g++.dg/debug/dwarf2/const1.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/const-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #5 from sfilippone at uniroma2 dot it 2010-05-15 07:19 ---
(In reply to comment #4)
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL initialization, both the $data and the $vptr components should be
zeroed.
Wild shot: has this anything to do with 43969?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-15 07:36 --- The actual failure is: libtool: compile: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-a pple-darwin10.3.0/lib/ -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/include -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/sys-include -DHAVE_CONFIG_H -I. -I../../../work/libgfortran -iquote../../../work/libgfortran/io -I../../../work/libgfortran/../gcc -I../../../work/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT fbuf.lo -MD -MP -MF .deps/fbuf.Tpo -c ../../../work/libgfortran/io/fbuf.c -fno-common -DPIC -o .libs/fbuf.old: warning: cannot export hidden symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() from .libs/comp lex_io.o ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from .libs/complex_io.o ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char const*, char const*, char, char*) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::underflow_error::~underflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::underflow_error::~underflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::overflow_error::~overflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::overflow_error::~overflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::range_error::~range_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::range_error::~range_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::out_of_range::~out_of_range() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::out_of_range::~out_of_range() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::length_error::~length_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::length_error::~length_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::invalid_argument::~invalid_argument() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::invalid_argument::~invalid_argument() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::domain_error::~domain_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::domain_error::~domain_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::system_error::system_error(std::error_code) from .libs/functexcept.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsputn(char const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::xsputn(wchar_t const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::xsgetn(wchar_t*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o) ld: codegen problem, can't use rel32 to external symbol
[Bug c++/44148] New: C++ genericization/gimplification may clobber templare arguments
template typename T struct S2
{
typedef const T t2;
t2 operator* () const {}
};
template typename T struct S3
{
typedef S2 T t5;
};
template typename T1, typename T2 T2 foo1 (T1 x, T2 y) { y (*x); }
template class T struct S4
{
T operator* () const;
};
struct S7 {};
struct S8
{
typedef::S3 S4 S7 ::t5 t6;
t6 m1 () const;
};
template class T struct S9
{
typedef T t3;
inline t3 operator[] (unsigned int) {}
};
template typename T1, typename T2, typename T3, void (T4) (const T1 , T3 )
struct S10
{
S10 (T2 x, unsigned int y = 0) : u (x), v (y) {}
void operator () (const S4 T1 x) { T4 (*x, u[v++]); }
T2 u;
unsigned int v;
};
struct S15;
struct S11
{
static void m3 (const S8 , S15 );
};
struct S16;
struct S12;
struct S13
{
static void m4 (const S7 desc,S16 toconfig);
};
typedef S10 S7, S12, S16, S13::m4 t10;
struct S12: S9 S16
{
};
struct S15
{
S12 p;
};
void S11::m3 (const S8 x, S15 y)
{
foo1 (x.m1 (), t10 (y.p));
}
ICEs with -fpic on x86_64-linux on redhat/gcc-4_4-branch. While it works
on the trunk, I believe this is a latent problem there.
The issue is that a template argument (nop_expr addr_expr baselink... )
is not unshared, so instantiated code can reference those trees and C++
genericization/gimplification then actually modifies not just the function
code, but also the template arguments. If anything from the template is later
on mangled, the mangling is different (baselink ... is replaced by
function_decl ...).
--
Summary: C++ genericization/gimplification may clobber templare
arguments
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44148
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-15 08:25 --- as of 159429 - m32 seems to be fixed (and m64 improved): === libgomp Summary for unix/-m32 === # of expected passes2490 # of unsupported tests 2 === libgomp Summary for unix/-m64 === # of expected passes2386 # of unexpected failures52 # of unsupported tests 2 -fails are all in libgomp.c++/ and libgomp.fortran/ (although that might be co-incidence). the fails seem to occur when an emutls variable is declared static. same situation applies to FE tls tests (m32 is OK modulo LTO issues, m64 has fails). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-15 08:29 --- note fails are for O 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:39 --- Subject: Re: [4.6 Regression] emutls is broken under a range of circumstances. The problem is because emultls is handling declarations in a way so references are not visible to middle end. I guess we need to put DECL_PRESERVE at the emultls variable so it stays innert. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:41 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 It appears that only darwin uses the set_user_assembler_name() call so we ought to be able to restore the previous behavior with... Does this help and if so, does changing the TREE_SYMBOL_REFERENCED set to mark_decl referenced as you proposed earlier work? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-15 08:47 --- (In reply to comment #3) The actual failure is: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) which (probably) makes this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132 (although I note the codegen problem, can't use rel32 to external symbol as distinct from a missing symbol - possibly a misleading err msg of course). Looking at my logs, I noticed that I successfully built revision 159376 with the Iain's patch in http://gcc.gnu.org/ml/gcc-patches/2010-05/txt00055.txt , does it make any sense? that patch should make no difference to this problem, and the problem it was addressing was solved by a different mechanism. I am trying to build 159429 on x86_64 and powerpc64 at present... (it bootstraps on i686). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-15 08:53 --- The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429 (now building libjava). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-15 08:59 --- (In reply to comment #4) Subject: Re: [4.6 Regression] emutls is broken under a range of circumstances. The problem is because emultls is handling declarations in a way so references are not visible to middle end. I guess we need to put DECL_PRESERVE at the emultls variable so it stays innert. Index: gcc/varasm.c === --- gcc/varasm.c(revision 159429) +++ gcc/varasm.c(working copy) @@ -386,6 +386,7 @@ emutls_decl (tree decl) DECL_TLS_MODEL (to) = TLS_MODEL_EMULATED; DECL_ARTIFICIAL (to) = 1; DECL_IGNORED_P (to) = 1; + DECL_PRESERVE_P (to) = 1; TREE_READONLY (to) = 0; SET_DECL_ASSEMBLER_NAME (to, DECL_NAME (to)); if (DECL_ONE_ONLY (decl)) looks good so far .. I'll have to wait for the bootstrap on x86_64 to succeed/fail to try it there too (PR44146 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-15 09:06 ---
(In reply to comment #0)
Windows targets that use emutls add a . character as a separator from the
_emutls_{t,v} and the true symbol name. However, exporting these symbol names
from a DLL is problematic (i.e. a thread local data variable), because the .
in the symbol name tells the Windows loader to treat the symbol as a
forwarding
RVA to a second DLL (in this case, it will look for the symbol varname in
__emutls_v.dll, the symbol exported is __emutls_v.varname). Note that this is
a runtime issue, not a compile/link issue.
I think it's actually a link time issue after all, and we could be going to
dodge a bullet re: having to break backward compatibility here. The PE spec
has this to say about forwarded exports (pe coff spec rev. 8, 6.3.2):
Each entry in the export address table is a field that uses one of two
formats in the following table. If the address specified is not within the
export section (as defined by the address and length that are indicated in the
optional header), the field is an export RVA, which is an actual address in
code or data. Otherwise, the field is a forwarder RVA, which names a symbol in
another DLL.
In other words, I don't think the runtime loader actually keys off the presence
of a dot in the exported symbol, but where the EAT entry points to. If we can
persuade ld that sometimes a dot in a .DEF file symbol listing is indeed just a
dot, and not a forwarder definition, it should be able to generate a regular
EAT entry pointing at the exported symbol, rather than placing an ASCII string
in the export section and pointing the EAT entry at it, and hopefully
everything should just work.
I'll test if this works by crudely hacking ld about a bit before thinking about
how we should implement this in terms of interface. We might be able to get
away without changing the compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #6 from iains at gcc dot gnu dot org 2010-05-15 09:25 --- (In reply to comment #5) Index: gcc/varasm.c === --- gcc/varasm.c(revision 159429) +++ gcc/varasm.c(working copy) @@ -386,6 +386,7 @@ emutls_decl (tree decl) DECL_TLS_MODEL (to) = TLS_MODEL_EMULATED; DECL_ARTIFICIAL (to) = 1; DECL_IGNORED_P (to) = 1; + DECL_PRESERVE_P (to) = 1; TREE_READONLY (to) = 0; SET_DECL_ASSEMBLER_NAME (to, DECL_NAME (to)); if (DECL_ONE_ONLY (decl)) looks good so far .. I'll have to wait for the bootstrap on x86_64 to succeed/fail to try it there too (PR44146 with this the FE problems (less LTO) are resolved and libgomp is restored less three C++ CTOR-related tests (ctor-5, ctor-8 and ctor-9). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #17 from a14331990 at hotmail dot com 2010-05-15 09:29 --- Created an attachment (id=20662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20662action=view) enable auto-import in ld This patch comes from a post by Dave Korn and is slightly modified by me [PATCH] Silence ld auto-import warnings for pe-i386. http://sourceware.org/ml/binutils/2009-02/msg00341.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #7 from iains at gcc dot gnu dot org 2010-05-15 09:29 --- (In reply to comment #6) The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429 (now building libjava). confirmed on an un-patched tree - I think this can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug lto/44149] New: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
The attached subroutine is compiled as follows: gfortran -c -flto -O2 -fwhole-program bkfconv.F90 and then the object file is placed in a library of its own: ar rv x.a bkfconv.o Subsequently, a main program, b.f: call deep_convection end is linked with this library, as follows: gfortran -fuse-linker-plugin -flto -O2 -fwhole-program b.f x.a This results in the ICE in the subject. gfortran -v Using built-in specs. COLLECT_GCC=/usr/snp/bin/gfortran COLLECT_LTO_WRAPPER=/usr/snp/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-checking=release --prefix=/usr/snp --enable-gold --enable-plugins --disable-multilib --disable-nls --with-arch-64=native --with-tune-64=native --enable-languages=fortran,c++ --enable-stage1-languages=c++ --disable-werror Thread model: posix gcc version 4.6.0 20100514 (experimental) (GCC) ld -v GNU gold (GNU Binutils 2.20.51.20100506) 1.9 -- Summary: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC host triplet: x64_86-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #18 from a14331990 at hotmail dot com 2010-05-15 09:31 --- Created an attachment (id=20663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20663action=view) don't emit dllexport'd inline functions This patch is just a removal of nathan's code. See r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines in gcc svn log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #1 from toon at moene dot org 2010-05-15 09:32 --- Created an attachment (id=20664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20664action=view) source code that shows the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-15 09:34 ---
(In reply to comment #1)
In other words, I don't think the runtime loader actually keys off the
presence
of a dot in the exported symbol, but where the EAT entry points to. If we can
persuade ld that sometimes a dot in a .DEF file symbol listing is indeed just
a
dot, and not a forwarder definition, it should be able to generate a regular
EAT entry pointing at the exported symbol, rather than placing an ASCII string
in the export section and pointing the EAT entry at it, and hopefully
everything should just work.
Theory confirmed by applying the following gross hack to src/ld/pe-dll.c:
Index: ld/pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.129
diff -p -u -r1.129 pe-dll.c
--- ld/pe-dll.c 28 Apr 2010 15:24:22 - 1.129
+++ ld/pe-dll.c 15 May 2010 09:32:37 -
@@ -867,7 +867,7 @@ process_def_file_and_drectve (bfd *abfd
char *name;
/* Check for forward exports */
- if (strchr (pe_def_file-exports[i].internal_name, '.'))
+ if (0 strchr (pe_def_file-exports[i].internal_name, '.'))
{
count_exported++;
if (!pe_def_file-exports[i].flag_noname)
Will attach the trivial testcase I tried it against.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #7 from hubicka at ucw dot cz 2010-05-15 09:35 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
Hi,
we can either go with DECL_PRESERVE that is kind of hack but makes situation no
worse.
Correct fix is to lower emultls earlier so both ipa-ref and LTO understands it.
This might be bit too early, but I think we can stick it into gimplifier as
follows
Index: expr.c
===
--- expr.c (revision 159421)
+++ expr.c (working copy)
@@ -6759,19 +6759,6 @@ highest_pow2_factor_for_target (const_tr
return MAX (factor, talign);
}
-/* Return VAR expression for emulated thread local VAR. */
-
-static tree
-emutls_var_address (tree var)
-{
- tree emuvar = emutls_decl (var);
- tree fn = built_in_decls [BUILT_IN_EMUTLS_GET_ADDRESS];
- tree arg = build_fold_addr_expr_with_type (emuvar, ptr_type_node);
- tree arglist = build_tree_list (NULL_TREE, arg);
- tree call = build_function_call_expr (UNKNOWN_LOCATION, fn, arglist);
- return fold_convert (build_pointer_type (TREE_TYPE (var)), call);
-}
-
/* Subroutine of expand_expr. Expand the two operands of a binary
expression EXP0 and EXP1 placing the results in OP0 and OP1.
@@ -6866,15 +6853,6 @@ expand_expr_addr_expr_1 (tree exp, rtx t
break;
case VAR_DECL:
- /* TLS emulation hook - replace __thread VAR's VAR with
-__emutls_get_address (_emutls.VAR). */
- if (! targetm.have_tls
- TREE_CODE (exp) == VAR_DECL
- DECL_THREAD_LOCAL_P (exp))
- {
- exp = emutls_var_address (exp);
- return expand_expr (exp, target, tmode, modifier);
- }
/* Fall through. */
default:
@@ -8406,16 +8384,6 @@ expand_expr_real_1 (tree exp, rtx target
(TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
layout_decl (exp, 0);
- /* TLS emulation hook - replace __thread vars with
-*__emutls_get_address (_emutls.var). */
- if (! targetm.have_tls
- TREE_CODE (exp) == VAR_DECL
- DECL_THREAD_LOCAL_P (exp))
- {
- exp = build_fold_indirect_ref_loc (loc, emutls_var_address (exp));
- return expand_expr_real_1 (exp, target, tmode, modifier, NULL);
- }
-
/* ... fall through ... */
case FUNCTION_DECL:
Index: gimplify.c
===
--- gimplify.c (revision 159421)
+++ gimplify.c (working copy)
@@ -1309,6 +1309,18 @@ gimplify_vla_decl (tree decl, gimple_seq
gimplify_ctxp-save_stack = true;
}
+/* Return VAR expression for emulated thread local VAR. */
+
+static tree
+emutls_var_address (tree var)
+{
+ tree emuvar = emutls_decl (var);
+ tree fn = built_in_decls [BUILT_IN_EMUTLS_GET_ADDRESS];
+ tree arg = build_fold_addr_expr_with_type (emuvar, ptr_type_node);
+ tree arglist = build_tree_list (NULL_TREE, arg);
+ tree call = build_function_call_expr (UNKNOWN_LOCATION, fn, arglist);
+ return fold_convert (build_pointer_type (TREE_TYPE (var)), call);
+}
/* Gimplifies a DECL_EXPR node *STMT_P by making any necessary allocation
and initialization explicit. */
@@ -1320,6 +1332,15 @@ gimplify_decl_expr (tree *stmt_p, gimple
tree decl = DECL_EXPR_DECL (stmt);
*stmt_p = NULL_TREE;
+ /* TLS emulation hook - replace __thread VAR's VAR with
+ __emutls_get_address (_emutls.VAR). */
+ if (! targetm.have_tls
+ TREE_CODE (decl) == VAR_DECL
+ DECL_THREAD_LOCAL_P (decl))
+{
+ *stmt_p = build_fold_indirect_ref (emutls_var_address (decl));
+ return GS_OK;
+}
if (TREE_TYPE (decl) == error_mark_node)
return GS_ERROR;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-15 09:37 --- Created an attachment (id=20665) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20665action=view) testcase: main executable source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-15 09:37 --- Created an attachment (id=20666) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20666action=view) testcase: dll source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #5 from davek at gcc dot gnu dot org 2010-05-15 09:38 --- Created an attachment (id=20667) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20667action=view) testcase: dll header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #6 from davek at gcc dot gnu dot org 2010-05-15 09:38 --- Created an attachment (id=20668) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20668action=view) testcase: makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-15 09:43 --- confirmed on an un-patched tree - I think this can be closed. I would prefer to leave it open until the causes of the breakage and the fix are known. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #7 from davek at gcc dot gnu dot org 2010-05-15 09:45 --- So... I think now we just need to figure out how to tell LD that some export directives contain dots because they're exporting a symbol containing a dot. Actually, that's probably all we need to do: when we find an export directive, before checking if there's a dot in it, check if it matches the name of an existing symbol and if so assume that that's the one we actually want to export. I'm going to close this bug and mark it as invalid, not because the report is incorrect in any way, but because I think this should be considered a binutils rather than GCC problem. Doug, you can open a PR in the sourceware.org bugzilla against binutils and assign it to me if you like, but I'll try not to forget about fixing this problem even if you don't! -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 10:21 --- (In reply to comment #5) Wild shot: has this anything to do with 43969? Actually I don't think so. At least the patch I posted yesterday does not fix PR43969: http://gcc.gnu.org/ml/fortran/2010-05/msg00155.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug fortran/43969] [OOP] CLASS(foo), ALLOCATABLE component bad initialization
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 10:25 --- (In reply to comment #1) Created an attachment (id=20542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20542action=view) [edit] Looking at the dump of this code shows: The $data component of int is being set to zero (correctly): try.int.$data = 0B; However, the ALLOCATED statement is being evaluated to .true: static logical(kind=4) C.1566 = 1; _gfortran_transfer_logical (dt_parm.0, C.1566, 4); -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-05-15 10:25:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
[Bug fortran/43969] [OOP] ALLOCATABLE with polymorphic variables
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 10:46 ---
Turns out that fixing this one is completely trivial, once you actually have a
look at it :)
The ALLOCATED intrinsic was just not adjusted to handle CLASS variables yet.
The patch is as simple as this:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 159389)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -4529,6 +4529,8 @@ gfc_conv_allocated (gfc_se *se, gfc_expr *expr)
{
/* Allocatable scalar. */
arg1se.want_pointer = 1;
+ if (arg1-expr-ts.type == BT_CLASS)
+ gfc_add_component_ref (arg1-expr, $data);
gfc_conv_expr (arg1se, arg1-expr);
tmp = arg1se.expr;
}
Thanks for the bug report, Salvatore.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-05-15 10:25:15 |2010-05-15 10:46:53
date||
Summary|[OOP] CLASS(foo), |[OOP] ALLOCATABLE with
|ALLOCATABLE component bad |polymorphic variables
|initialization |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-15 11:24 --- (In reply to comment #7) Subject: Re: [4.6 Regression] emutls is broken under a range of circumstances. Correct fix is to lower emultls earlier so both ipa-ref and LTO understands it. This might be bit too early, but I think we can stick it into gimplifier as follows works except where the var is initialized... where an init var is present, the compiler appears to be emitting native TLS code .. :-( so I guess there's another arm that needs to be intercepted .. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-15 11:32 --- I'd rather go with the DECL_PRESERVE_P hack for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug fortran/43969] [OOP] ALLOCATED() with polymorphic variables
--- Comment #5 from sfilippone at uniroma2 dot it 2010-05-15 11:33 ---
(In reply to comment #4)
Turns out that fixing this one is completely trivial, once you actually have a
look at it :)
The ALLOCATED intrinsic was just not adjusted to handle CLASS variables yet.
The patch is as simple as this:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 159389)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -4529,6 +4529,8 @@ gfc_conv_allocated (gfc_se *se, gfc_expr *expr)
{
/* Allocatable scalar. */
arg1se.want_pointer = 1;
+ if (arg1-expr-ts.type == BT_CLASS)
+ gfc_add_component_ref (arg1-expr, $data);
gfc_conv_expr (arg1se, arg1-expr);
tmp = arg1se.expr;
}
Thanks for the bug report, Salvatore.
While we are at it, shouldn't the error message on ALLOCATE be changed to
reflect the fact that not only arrays but also scalars might be allocatables?
(see #2)
Salvatore
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #19 from stahta01 at students dot ipfw dot edu 2010-05-15 11:53 --- Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix this problem? Option found on http://gcc.gnu.org/wiki/Visibility. Note: The MinGW GCC 4.5.0-1 does not make smaller DLLs using above options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-15 11:57 --- hmm - that certainly looks simpler... I guess, otherwise, we have to intercept every circumstance where a __thread var might be used .. and interpose the exchange. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #8 from dougsemler at gmail dot com 2010-05-15 13:03 --- Done cf. http://sourceware.org/bugzilla/show_bug.cgi?id=11603 (note to self, pay more attention to specs and less attention to de facto behavior of toolsets ;-)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #20 from a14331990 at hotmail dot com 2010-05-15 13:24 --- (In reply to comment #19) Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix this problem? Option found on http://gcc.gnu.org/wiki/Visibility. Note: The MinGW GCC 4.5.0-1 does not make smaller DLLs using above options. I don't think these option can undo the change by nathan at 2009-05-22 r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines gcc/ * tree.c (handle_dll_attribute): Mark dllexport'd inlines as non-external. gcc/cp * decl2.c (decl_needed_p): Consider dllexport'd functions needed. * semantics.c (expand_or_defer_fn): Similarly. gcc/testsuite/ * gcc.dg/dll-6.c: New test. * gcc.dg/dll-6a.c: Likewise. * gcc.dg/dll-7.c: Likewise. * gcc.dg/dll-7a.c: Likewise. * g++.dg/ext/dllexport2.C: Likewise. * g++.dg/ext/dllexport2a.cc: Likewise. BTW, say SORRY to nathan, your change is indeed useful for building libstdc++ dll, but I have found an alternative approach. Indeed, the explanation page http://gcc.gnu.org/wiki/Visibility says How to use the new C++ visibility support In your header files, wherever you want an interface or API made public outside the current DSO, place __attribute__((visibility(default))) in struct, class and function declarations you wish to make public (it's easier if you define a macro as this). You don't need to specify it in the definition. Then, alter your make system to pass -fvisibility=hidden to each call of GCC compiling a source file., this means to use these options, you should alter your header files first, but wxwidgets source code apparently don't contain anything like __attribute__((visibility(default))). Correct me if I'm wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #9 from davek at gcc dot gnu dot org 2010-05-15 13:48 --- FTR: Patch posted at http://sourceware.org/ml/binutils/2010-05/msg00171.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #11 from hubicka at ucw dot cz 2010-05-15 13:48 --- Subject: Re: [4.6 Regression] emutls is broken under a range of circumstances. I'd rather go with the DECL_PRESERVE_P hack for now. Problem with this is that emultls is still broken with LTO. As soon as we merge multiple emultls vars from multiple units, we will screw up at expansion time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #12 from hubicka at ucw dot cz 2010-05-15 13:49 --- Subject: Re: [4.6 Regression] emutls is broken under a range of circumstances. I guess, otherwise, we have to intercept every circumstance where a __thread var might be used .. and interpose the exchange. Hmm, does combination of PRESERVE hack and the gimplifier change gets the testsuite clean and both LTO/WHOR working? You can construct a testcase where you have two source units both having thread local variables with uses all intlined into main(). This is case where I think the DECL_PRESERVE hack should fall appart. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug fortran/43969] [OOP] ALLOCATED() with polymorphic variables
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 13:52 --- Subject: Bug 43969 Author: janus Date: Sat May 15 13:52:33 2010 New Revision: 159431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159431 Log: 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/43207 PR fortran/43969 * gfortran.h (gfc_class_null_initializer): New prototype. * expr.c (gfc_class_null_initializer): New function to build a NULL initializer for CLASS pointers. * symbol.c (gfc_build_class_symbol): Modify internal naming of class containers. Remove default NULL initialization of $data component. * trans.c (gfc_allocate_array_with_status): Fix wording of an error message. * trans-expr.c (gfc_conv_initializer,gfc_trans_subcomponent_assign): Use new function 'gfc_class_null_initializer'. * trans-intrinsic.c (gfc_conv_allocated): Handle allocatable scalar class variables. 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/43207 PR fortran/43969 * gfortran.dg/class_18.f03: New. * gfortran.dg/class_19.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_18.f03 trunk/gcc/testsuite/gfortran.dg/class_19.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 13:52 --- Subject: Bug 43207 Author: janus Date: Sat May 15 13:52:33 2010 New Revision: 159431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159431 Log: 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/43207 PR fortran/43969 * gfortran.h (gfc_class_null_initializer): New prototype. * expr.c (gfc_class_null_initializer): New function to build a NULL initializer for CLASS pointers. * symbol.c (gfc_build_class_symbol): Modify internal naming of class containers. Remove default NULL initialization of $data component. * trans.c (gfc_allocate_array_with_status): Fix wording of an error message. * trans-expr.c (gfc_conv_initializer,gfc_trans_subcomponent_assign): Use new function 'gfc_class_null_initializer'. * trans-intrinsic.c (gfc_conv_allocated): Handle allocatable scalar class variables. 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/43207 PR fortran/43969 * gfortran.dg/class_18.f03: New. * gfortran.dg/class_19.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_18.f03 trunk/gcc/testsuite/gfortran.dg/class_19.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug middle-end/44150] New: [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
On Linux/ia32, revision 159428 gave: FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr Revision 159421 is OK. -- Summary: [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-15 14:00 --- It is caused by revision 159428: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00480.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug fortran/43207] [OOP] invalid pointer assignment = type%parent
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 14:08 --- r159431 fixes the ICE. Comment #0 is now accepted without an error message. -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |accepts-invalid Summary|[OOP] ICE for class pointer |[OOP] invalid pointer |= null() initialization|assignment = type%parent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug fortran/43969] [OOP] ALLOCATED() with polymorphic arrays
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 14:18 --- r159431 fixes the problems with allocatable scalar class variables in comment #1 and #2, and also the wording of the error message reported in comment #5. However, the ALLOCATED intrinsic still gives a gimplification error for allocatable class arrays: type foo end type class(foo), allocatable :: aca(:) write(*,*) 'Check on allocated: ', allocated(aca) end -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |ice-on-valid-code Summary|[OOP] ALLOCATED() with |[OOP] ALLOCATED() with |polymorphic variables |polymorphic arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
[Bug middle-end/44151] New: [4.6 regression] non-const variable in read-only section
Revision 159325 breaks libjava on powerpc. The variable java::lang::Class::class$ is wrongly put in the read-only section. -- Summary: [4.6 regression] non-const variable in read-only section Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at linux-m68k dot org GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44151
[Bug bootstrap/44079] Bootstrap error about elf_getshdrstrndx when configure script does not detect elf_getshdrstrndx
--- Comment #3 from mikereape at onetel dot com 2010-05-15 15:07 --- Subject: Re: Bootstrap error about elf_getshdrstrndx when configure script does not detect elf_getshdrstrndx On 05/15/2010 03:53 AM, soni dot sandeepb at gmail dot com wrote: --- Comment #2 from soni dot sandeepb at gmail dot com 2010-05-15 02:53 --- (In reply to comment #1) Could you please provide some more details, please: what system are you running on, what version of libelf is in use? And please provide config.log and configure output from the toplevel and from the gcc subdirectory, together with gcc/auto-host.h. [sa...@sandy ~]$ uname -r 2.6.29.4-167.fc11.i686.PAE Currently, I am unable to reproduce the configure output since now I am working with elfutils-libelf-devel-0.145-1 which, it seems, has fixed the problem. Earlier, I was using elfutils-libelf-devel-0.140-1 which came installed with the distro. I also had libelf 0.8.13 on my system at the time of this bug but that was insufficient to resolve the bug. Maybe Mike can reproduce the configure and config.log output. Hi, I am currently unable to reproduce the output due to a changing configuration as well. I may be able to do it but it won't be for at least another three days. My apologies, Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44079
[Bug other/44038] [4.5 regression] ICE: verify_stmts failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-15 15:07 --- Fixed on the trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.4.5 |4.4.5 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44038
[Bug other/44038] [4.5 regression] ICE: verify_stmts failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-15 15:07 --- Subject: Bug 44038 Author: rguenth Date: Sat May 15 15:06:47 2010 New Revision: 159434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159434 Log: 2010-05-15 Richard Guenther rguent...@suse.de PR tree-optimization/44038 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Avoid taking the address of a V_C_E of a constant. * gcc.c-torture/compile/pr44038.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr44038.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44038
[Bug middle-end/44151] [4.6 regression] non-const variable in read-only section
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-15 15:10 --- Should be fixed with r159414. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44151
[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug lto/44152] New: ICE on compiling xshow.f of xplor-nih with -O3 -ffast-math -fwhopr
The compilation of xshow.f of the xplor-nih package causes a compiler ICE for... gfortran -c xshow.f -O3 -ffast-math -fwhopr -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore xshow.f:295.7: HEAP(VSTACK),HEAP(LSTACK), 1 Warning: Type mismatch in argument 'vstack' at (1); passed INTEGER(8) to COMPLEX(8) xshow.f:367.7: HEAP(VSTACK),HEAP(LSTACK),HEAP(INDEX),HEAP(HPH), 1 Warning: Type mismatch in argument 'vstack' at (1); passed INTEGER(8) to COMPLEX(8) xshow.f: In function xshow_: xshow.f:2:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This doesn't occur with -O2 -ffast-math -fwhopr and also is triggered by the minimal subset of compiler options -O2 -fipa-cp-clone -ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math -fwhopr. The segmentation fault backtraces in gdb as... (gdb) r xshow.f -ffixed-form -fPIC -quiet -dumpbase xshow.f -mmacosx-version-min=10.6.3 -mtune=generic -auxbase xshow -O2 -version -fipa-cp-clone -ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math -fwhopr -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore -fintrinsic-modules-path /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.3.0/4.6.0/finclude -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccdh1126.s Starting program: /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.3.0/4.6.0/f951 xshow.f -ffixed-form -fPIC -quiet -dumpbase xshow.f -mmacosx-version-min=10.6.3 -mtune=generic -auxbase xshow -O2 -version -fipa-cp-clone -ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math -fwhopr -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore -fintrinsic-modules-path /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.3.0/4.6.0/finclude -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccdh1126.s Reading symbols for shared libraries .. done GNU Fortran (GCC) version 4.6.0 20100515 (experimental) [trunk revision 159301] (x86_64-apple-darwin10.3.0) compiled by GNU C version 4.6.0 20100515 (experimental) [trunk revision 159301], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.0 20100515 (experimental) [trunk revision 159301] (x86_64-apple-darwin10.3.0) compiled by GNU C version 4.6.0 20100515 (experimental) [trunk revision 159301], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 xshow.f:295.7: HEAP(VSTACK),HEAP(LSTACK), 1 Warning: Type mismatch in argument 'vstack' at (1); passed INTEGER(8) to COMPLEX(8) xshow.f:367.7: HEAP(VSTACK),HEAP(LSTACK),HEAP(INDEX),HEAP(HPH), 1 Warning: Type mismatch in argument 'vstack' at (1); passed INTEGER(8) to COMPLEX(8) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0004 vect_mark_slp_stmts (node=value temporarily unavailable, due to optimizations, mark=pure_slp, j=-1) at ../../gcc-4.6-20100515/gcc/tree-vect-slp.c:2391 2391} (gdb) bt #0 vect_mark_slp_stmts (node=value temporarily unavailable, due to optimizations, mark=pure_slp, j=-1) at ../../gcc-4.6-20100515/gcc/tree-vect-slp.c:2391 #1 0x00010072e754 in vect_make_slp_decision (loop_vinfo=0x1425dd990) at ../../gcc-4.6-20100515/gcc/tree-vect-slp.c:1261 #2 0x000100725a5b in vect_analyze_loop (loop=value temporarily unavailable, due to optimizations) at ../../gcc-4.6-20100515/gcc/tree-vect-loop.c:1495 #3 0x00010073144a in vectorize_loops () at ../../gcc-4.6-20100515/gcc/tree-vectorizer.c:219 #4 0x00010056185a in execute_one_pass (pass=0x100aeefc0) at ../../gcc-4.6-20100515/gcc/passes.c:1591 #5 0x000100561afd in execute_pass_list (pass=0x100aeefc0) at ../../gcc-4.6-20100515/gcc/passes.c:1646 #6 0x000100561b0f in execute_pass_list (pass=0x100aef1a0) at ../../gcc-4.6-20100515/gcc/passes.c:1647 #7 0x000100561b0f in execute_pass_list (pass=0x100aee3c0) at ../../gcc-4.6-20100515/gcc/passes.c:1647 #8 0x000100659ba5 in tree_rest_of_compilation (fndecl=0x142643f00) at ../../gcc-4.6-20100515/gcc/tree-optimize.c:413 #9 0x0001007b6950 in cgraph_expand_function (node=0x14240aa80) at ../../gcc-4.6-20100515/gcc/cgraphunit.c:1622 #10 0x0001007b8cc9 in cgraph_optimize () at ../../gcc-4.6-20100515/gcc/cgraphunit.c:1701 #11 0x0001007b91ea in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20100515/gcc/cgraphunit.c:1161 #12 0x000100501b36 in write_global_declarations () at ../../gcc-4.6-20100515/gcc/langhooks.c:309 #13 0x000100613620 in toplev_main (argc=26, argv=0x7fff5fbfed68) at ../../gcc-4.6
[Bug lto/44152] ICE on compiling xshow.f of xplor-nih with -O3 -ffast-math -fwhopr
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-15 15:21 --- Created an attachment (id=20669) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20669action=view) testcase for xshow.f -O2 -fipa-cp-clone -ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math -fwhopr ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44152
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #13 from iains at gcc dot gnu dot org 2010-05-15 15:40 --- see: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a workaround -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #21 from iains at gcc dot gnu dot org 2010-05-15 15:40 --- updated: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-15 15:45 --- The failure is back at revision 159433, now with: ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::xsputn(wchar_t const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::xsgetn(wchar_t*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o) ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-05-15 15:55 --- I'm working on this (designing an algorithm so far). It is an interesting problem. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-14 08:26:12 |2010-05-15 15:55:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug lto/44152] ICE on compiling xshow.f of xplor-nih with -O3 -ffast-math -fwhopr
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-15 16:08 --- AFAICT -fwhole-file is enough to get the ICE: '-O2 -fipa-cp-clone -ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math -fwhole-file'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44152
[Bug fortran/43996] ICE in simplification of spread intrinsic
--- Comment #13 from dominiq at lps dot ens dot fr 2010-05-15 16:43 --- AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE reported in comment #0 without patching gcc/fortran/simplify.c as in comment #0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
[Bug debug/44112] [4.6 regression] Revision 159354 causes Fortran test failures
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-15 16:51 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
[Bug middle-end/44103] [4.6 Regression] New Java test failures
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-15 16:52 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #4 from dominiq at lps dot ens dot fr 2010-05-15 17:05 --- It is an interesting problem. Should not it be handled by the middle-end, possibly with the help of graphite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-05-15 17:30 --- (In reply to comment #4) It is an interesting problem. Should not it be handled by the middle-end, possibly with the help of graphite? If we can improve dependency analysis in the front end, where we (potentially) have some more information, it should not hurt the middle-end. OTOH, if somebody is already doing work in this direction, it would be a waste to duplicate. So... is any work going on with this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-15 18:01 --- If we can improve dependency analysis in the front end, where we (potentially) have some more information, it should not hurt the middle-end. OTOH, if somebody is already doing work in this direction, it would be a waste to duplicate. So... is any work going on with this? I think Paul Thomas has something in his files, but I don't have any pointer at hand (IIRC along the line a(2:n)=a(1:n-1) replaced with a(n:2:-1)=a(n-1:1:-1)). I have given some thoughts to the problem a while ago, but did not go further than the easy cases, such as the one in the example, are easy;-) but writing something general quite difficult. In top of that what is already implemented is documented only in the code. I think if you start this problem, it would be worth to look at what is done in the middle-end (or in graphite) and what can be reused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-05-15 18:13 --- I suggest you give a chat to Richard Guenther who seems quite up on the optimisation aspects of things. If we are creating a temporary in the front end I think that would be the least optimal approach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-05-15 18:48 --- Suppressed as by reverting r159371 with... diff -uNr gcc-4.6-20100514/gcc/varpool.c gcc-4.6-20100514.hubicka/gcc/varpool.c --- gcc-4.6-20100514/gcc/varpool.c 2010-05-14 19:37:24.0 -0400 +++ gcc-4.6-20100514.hubicka/gcc/varpool.c 2010-05-14 19:45:35.0 -0400 @@ -321,6 +321,13 @@ || node-force_output) return true; + /* ??? If the assembler name is set by hand, it is possible to assemble + the name later after finalizing the function and the fact is noticed + in assemble_name then. This is arguably a bug. */ + if (TARGET_MACHO DECL_ASSEMBLER_NAME_SET_P (decl) + TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) +return true; + /* Externally visible variables must be output. The exception is COMDAT variables that must be output only when they are needed. */ if (TREE_PUBLIC (decl) to reintroduce this for darwin only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #11 from dominiq at lps dot ens dot fr 2010-05-15 19:27 --- (In reply to comment #10) Suppressed as by reverting r159371 with... Confirmed at revision 159435. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug libmudflap/32276] [4.3/4.4/4.5/4.6 Regression]: libmudflap.c++/pass41-frag.cxx
--- Comment #15 from ubizjak at gmail dot com 2010-05-15 19:43 --- This PR was fixed somewhere between r158731 [1] and r158736 [2]. The only relevant commit in this range is [3, 4]. [1] http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02458.html [2] http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02468.html [3] http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html [4] http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01594.html Let's mark this PR fixed for 4.6. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-15 19:53 --- A few comments: (1) adding -flto or -fwhopr solves the linking problem for the polyhedron tests and the reduced one in comment #1. (2) the test in comment #4 is different as it shows up for -fwhole-file and is not solved with -flto or -fwhopr. (3) I have been puzzled by the results in http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ for fatigue.f90. It is due to -fwhole-program: [macbook] lin/test% gfc -O3 -ffast-math -fwhole-file -flto fatigue.f90 [macbook] lin/test% time a.out ... 9.223u 0.004s 0:09.23 99.8% 0+0k 0+0io 0pf+0w [macbook] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90 [macbook] lin/test% time a.out ... 6.482u 0.004s 0:06.49 99.8% 0+0k 0+0io 0pf+0w It would be interesting to understand why and to keep this nice speed up when fixing this pr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/44064] [OOP] ICE with file containing two modules and one program
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-15 20:02 --- Here is a slightly reduced test case: module module_myclass implicit none type :: inner contains procedure :: set end type type :: myclass type(inner) :: slice end type contains subroutine set(this) class(inner), intent(inout) :: this end subroutine set end module module_myclass module module_mysubclass use module_myclass, only : myclass implicit none contains subroutine init(this) class(myclass), intent(inout) :: this call this%slice%set() ! XXX PROBLEM HERE end subroutine init end module module_mysubclass program test use module_mysubclass implicit none end program For this I get a segfault with the following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00550bb7 in gfc_find_symtree (st=0x1711, name=0x77f2aec0 vtype$inner) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2393 2393 c = strcmp (name, st-name); (gdb) bt #0 0x00550bb7 in gfc_find_symtree (st=0x1711, name=0x77f2aec0 vtype$inner) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2393 #1 0x00550b62 in gfc_delete_symtree (root=0x17af7e0, name=0x77f2aec0 vtype$inner) at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2374 #2 0x005517bd in gfc_undo_symbols () at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2845 #3 0x005139fd in decode_statement () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:271 #4 0x0051522c in next_free () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:722 #5 0x005155fc in next_statement () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:907 #6 0x0051999d in gfc_parse_file () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4220 #7 0x0055a36b in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/trunk/gcc/fortran/f95-lang.c:239 #8 0x00a1539f in compile_file () at /home/jweil/gcc46/trunk/gcc/toplev.c:1049 #9 0x00a1769d in do_compile () at /home/jweil/gcc46/trunk/gcc/toplev.c:2393 #10 0x00a17773 in toplev_main (argc=2, argv=0x7fffe2f8) at /home/jweil/gcc46/trunk/gcc/toplev.c:2435 #11 0x005e262c in main (argc=2, argv=0x7fffe2f8) at /home/jweil/gcc46/trunk/gcc/main.c:35 -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-15 20:02:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
[Bug lto/44153] New: ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1194
$ LANG=C make clean all LTOFLAGS=-fwhopr rm -f *.o *.s *.ii m g++ -Wall -g0 -O3 -fwhopr a.cpp -c g++ -Wall -g0 -O3 -fwhopr m.cpp -c g++ -Wall -g0 -O3 -fwhopr a.o m.o -o m lto1: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1194 -- Summary: ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1194 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44153
[Bug lto/44153] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1194
--- Comment #1 from pluto at agmk dot net 2010-05-15 20:04 --- Created an attachment (id=20670) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20670action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44153
[Bug fortran/44154] New: initialization problem with allocatable scalars
Reported by Steve Kargl: FAIL: gfortran.dg/class_19.f03 -O0 execution test Reduced/modified test case: implicit none type foo integer, allocatable :: int(:) end type type(foo),allocatable :: try allocate(try) end This gives (with 4.5 and trunk): Fortran runtime error: Attempting to allocate already allocated variable 'try' The runtime error goes away when removing the allocatable component of 'foo' or making it non-allocatable. With the allocatable component, the dump is missing a line like: try = 0B; i.e. the allocatable scalar is not set to zero in the beginning. If 'foo' is an allocatable array, everything is fine. -- Summary: initialization problem with allocatable scalars Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
[Bug c++/44148] C++ genericization/gimplification may clobber templare arguments
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-15 20:24 --- Subject: Bug 44148 Author: jakub Date: Sat May 15 20:23:59 2010 New Revision: 159443 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159443 Log: PR c++/44148 * pt.c (tsubst): Unshare template argument. * g++.dg/torture/pr44148.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr44148.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44148
[Bug c++/44148] C++ genericization/gimplification may clobber templare arguments
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-15 20:29 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44148
[Bug middle-end/44151] [4.6 regression] non-const variable in read-only section
--- Comment #2 from schwab at linux-m68k dot org 2010-05-15 20:35 --- *** This bug has been marked as a duplicate of 44103 *** -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44151
[Bug middle-end/44103] [4.6 Regression] New Java test failures
--- Comment #4 from schwab at linux-m68k dot org 2010-05-15 20:35 --- *** Bug 44151 has been marked as a duplicate of this bug. *** -- schwab at linux-m68k dot org changed: What|Removed |Added CC||schwab at linux-m68k dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
[Bug fortran/44154] initialization problem with allocatable scalars
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-15 20:43 ---
Here is the fix:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 159433)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -3259,8 +3259,6 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, tr
if (sym_has_alloc_comp !seen_trans_deferred_array)
fnbody = gfc_trans_deferred_array (sym, fnbody);
}
- else if (sym_has_alloc_comp)
- fnbody = gfc_trans_deferred_array (sym, fnbody);
else if (sym-attr.allocatable
|| (sym-ts.type == BT_CLASS
sym-ts.u.derived-components-attr.allocatable))
@@ -3298,6 +3296,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, tr
fnbody = gfc_finish_block (block);
}
}
+ else if (sym_has_alloc_comp)
+ fnbody = gfc_trans_deferred_array (sym, fnbody);
else if (sym-ts.type == BT_CHARACTER)
{
gfc_get_backend_locus (loc);
The problem was simply that the branches in the if statement were in the wrong
order, so that nullification of an allocatable scalar was missed if it had
allocatable components.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-05-15 20:43:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
[Bug fortran/43996] ICE in simplification of spread intrinsic
--- Comment #14 from dominiq at lps dot ens dot fr 2010-05-15 21:21 --- (In reply to comment #13) AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE reported in comment #0 without patching gcc/fortran/simplify.c as in comment comment #0. No longer true at revision 159435!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
[Bug fortran/44154] initialization problem with allocatable scalars
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-15 21:24 --- This PR looks related to pr42647. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-15 21:25 --- See also pr44154. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-15 21:40:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #12 from dominiq at lps dot ens dot fr 2010-05-15 21:50 --- I have looked to my logs and the warnings ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from .libs/complex_io.o ... are already in my make log for revision 154675. In fact the key error is the same in the failures I have recorded: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug fortran/44154] initialization problem with allocatable scalars
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 22:03 --- Subject: Bug 44154 Author: janus Date: Sat May 15 22:03:09 2010 New Revision: 159445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159445 Log: 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/44154 PR fortran/42647 * trans-decl.c (gfc_trans_deferred_vars): Modify ordering of if branches. 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/44154 PR fortran/42647 * gfortran.dg/allocatable_scalar_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 22:03 --- Subject: Bug 42647 Author: janus Date: Sat May 15 22:03:09 2010 New Revision: 159445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159445 Log: 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/44154 PR fortran/42647 * trans-decl.c (gfc_trans_deferred_vars): Modify ordering of if branches. 2010-05-15 Janus Weil ja...@gcc.gnu.org PR fortran/44154 PR fortran/42647 * gfortran.dg/allocatable_scalar_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug fortran/44154] initialization problem with allocatable scalars
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 22:05 --- (In reply to comment #2) This PR looks related to pr42647. Thanks for the remark, Dominique. I think they're pretty much identical. The commit (r159445) includes PR42647 comment #2/#3 as a test case. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 22:16 --- r159445 should fix all the initialization trouble. Comment #2/#3 has been included as a test case. For the automatic deallocation there is be a problem remaining: In comment #0, a itself is now automatically deallocated, but not a%d any more. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-15 22:16:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 22:29 --- (In reply to comment #7) For the automatic deallocation there is be a problem remaining: In comment #0, a itself is now automatically deallocated, but not a%d any more. This is fixed by this patchlet (which is part of patch in comment #1): Index: gcc/fortran/trans-decl.c === --- gcc/fortran/trans-decl.c(revision 159445) +++ gcc/fortran/trans-decl.c(working copy) @@ -3272,6 +3272,9 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, tr gfc_se se; stmtblock_t block; + if (sym_has_alloc_comp) + fnbody = gfc_trans_deferred_array (sym, fnbody); + e = gfc_lval_expr_from_sym (sym); if (sym-ts.type == BT_CLASS) gfc_add_component_ref (e, $data); Also the use-association issue still needs to be taken care of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-15 22:49 --- OK, here's what's going wrong: The LTO design is such that EH is only enabled if we encounter a function with an EH personality. With -fwhopr we process one translation unit at a time, so when we look at 20081109_1.C we only see foo(int). Before my patch foo(int) contained an ERT_MUST_NOT_THROW region, so we required the C++ personality function. After my patch, it contains an ERT_CLEANUP region instead, which doesn't require the C++ personality function So cgraph doesn't set DECL_FUNCTION_PERSONALITY, so lto1 doesn't think that foo needs EH, so it never sets flag_exceptions, so we don't get unwind information, so the throw can't unwind through foo. There seem to be two issues here: 1) lto1 incorrectly thinks foo doesn't need EH. 2) -fwhopr means that lto1 can make different decisions about EH for different translation units, so things blow up when linked together. With #2 fixed, #1 isn't as big a problem--but it could still be an issue if we aren't compiling the entire program, i.e. a shared library wants to throw from a callback. If anything we call can throw, we need unwind information and should turn on -fexceptions. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Component|middle-end |lto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-15 23:04 --- Why is flag_exceptions not just streamed out/in with other options? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #13 from iains at gcc dot gnu dot org 2010-05-16 00:24 --- (In reply to comment #12) ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) yep - this is the problem child. 1/ there is a difference between m32 and m64 (I guess, because the linker islands capability is assumed for m64 - and the emitted code is different). 2/ m64 we get this : mini-02-sno:gcc-4-6-trunk-build $ otool -rv x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu 002c True long True BRANCH False ___emutls_get_address 0024 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global 000c True long True BRANCH False ___emutls_get_address 0004 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global note ^^^ these are long rather than quad. mini-02-sno:gcc-4-6-trunk-build $ nm x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu nm: no name list nm: no name list U ___emutls_get_address 0b40 d ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global nm: no name list note ... ^ this is a non-exported symbol. Possibly the reason that this fault comes goes could be that it depends on how the data segment is laid out. that doesn't really explain why this should be repeatably affected by the reversion of 159371.. I'll try and produce some analysis of the non-working case next .. but the day job needs some attention ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-16 00:56 --- in the compilation of eh_globals.cc: the i686-apple-darwin9 compiler does *not* produce any emutls refs (at m32 or m64) - but rather all the thread stuff is handled via pthread interfaces. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2010-05-16 02:07 --- The testcase fails with -O2 -funroll-loops. It works with -O2. The problem occurs in main at line 89, which is the second doit call. We get a segfault when dereferencing a null pointer. The code is wrong because of an instruction-scheduling/if-conversion/alias-analysis issue. In the broken assembly output, we have (over simplified) addl r33 = @ltoffx(__s_bar_mod_MOD_vtab$s_bar#), r1 ld8.mov r29 = [r33], __s_bar_mod_MOD_vtab$s_bar# adds r28 = 24, r29 ld8 r26 = [r28] cmp.ne p6, p7 = 0, r31 (p7) adds r31 = 24, r29 (p7) addl r30 = @ltoff(@fptr(__s_bar_mod_MOD_doit#)), gp (p7) ld8 r30 = [r30] (p7) st8 [r31] = r30 ld8 r27 = [r26], 8 And the last instruction segfaults because r26 is 0 when it should be the address of __s_bar_mod_MOD_doit. The load from r28 should not have been moved before the group of conditional instructions. This is correct up to the mach pass, where the IA-64 port runs the second instruction scheduling pass. The first instruction scheduling pass is before if-conversion, so we still have a branch around a block of instructions there. I'm seeing different instruction scheduling and bundle filling with -funroll-loops, though it isn't immediately clear why, as there are no loops here. I'm getting the same code with a x86-linux cross ia64-linux compiler. Just look for the code using __s_bar_mod_MOD_vtab$s_bar and __s_bar_mod_MOD_doit in main. So it should be possible to debug this on an x86-linux machine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-16 02:07:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug fortran/44155] New: gfortran segmentation fault using iso_c_binding
gfortran encounters a segfault when trying to compile a standalone file. The source file itself appears at the end of this comment. But first, the gfortran behavior users/whalen gfortran -v -save-temps test.f90 Driving: gfortran -v -save-temps test.f90 -lgfortran -lm -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=gcc/dev/20100515/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../src/gcc-dev/configure --prefix=gcc/dev/20100515/ --with-gmp=gmp/4.3.2/ --with-mpfr=mpfr/2.4.2/ --with-mpc=mpc/0.8.1/ --with-ppl=ppl/0.10.2/ --with-cloog=cloog/0.15.9/ --enable-languages=fortran,c,c++ --enable-lto --with-libelf=libelf/0.8.13 Thread model: posix gcc version 4.6.0 20100516 (experimental) [trunk revision 159450] (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' gcc/dev/20100515/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path gcc/dev/20100515/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o test.s GNU Fortran (GCC) version 4.6.0 20100516 (experimental) [trunk revision 159450] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100516 (experimental) [trunk revision 159450], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20100516 (experimental) [trunk revision 159450] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100516 (experimental) [trunk revision 159450], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 test.f90: In function tetgenf: test.f90:125:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. users/whalen cat test.f90 module mod_tetgen use iso_c_binding implicit none type tetgenpolygon logical :: initialized = .false. integer :: numberofvertices = 0 integer, pointer :: vertexlist(:) end type tetgenpolygon type tetgenfacet logical :: initialized = .false. integer :: numberofpolygons = 0 type(tetgenpolygon), pointer :: polygonlist(:) integer :: numberofholes = 0 double precision, pointer :: holelist(:,:) end type tetgenfacet type tetgenio logical :: initialized = .false. integer :: handle = -1 integer :: numberofpoints = 0 double precision, pointer :: pointlist(:,:) integer :: numberoffacets = 0 type(tetgenfacet), pointer :: facetlist(:) integer, pointer :: facetmarkerlist(:) end type tetgenio interface subroutine tetcall (inhandle, outhandle, numberofpoints, pointlist, numberoffacets, numberofpolygons, numberofholes, facetmarkerlist, vertexliststarts, vertexlistvals, numberofoutpoints, outpointlist, numberofoutfacets) bind(c) use iso_c_binding implicit none integer(c_int), value :: inhandle integer(c_int), value :: outhandle integer(c_int), value :: numberofpoints type(c_ptr), value:: pointlist integer(c_int), value :: numberoffacets type(c_ptr), value:: numberofpolygons type(c_ptr), value:: numberofholes type(c_ptr), value:: facetmarkerlist type(c_ptr), value:: vertexliststarts, vertexlistvals integer(c_int):: numberofoutpoints type(c_ptr) :: outpointlist integer(c_int):: numberofoutfacets end subroutine tetcall end interface contains subroutine tetgenf( in, out ) implicit none !-- Transferred variables type(tetgenio), target, intent(in):: in type(tetgenio), target, intent(inout) :: out !-- Local variables integer ppos, vpos integer f, p, v type(tetgenfacet), pointer :: pfacet type(tetgenpolygon), pointer :: ppoly integer, allocatable, target :: npolylist(:), nholelist(:) integer, allocatable, target :: vertexliststarts(:), vertexlistvals(:) integer inhandle, outhandle type(c_ptr) c_outpointlist allocate(npolylist(in%numberoffacets)) allocate(nholelist(in%numberoffacets)) ppos = 1 vpos = 1 do f = 1, in%numberoffacets pfacet = in%facetlist(f) do p = 1, pfacet%numberofpolygons ppoly = pfacet%polygonlist(p) do v = 1, ppoly%numberofvertices vpos = vpos + 1 end do ppos = ppos + 1 end do end do allocate(vertexliststarts(ppos), vertexlistvals(vpos-1)) ppos = 1 vpos = 1 do f = 1, in%numberoffacets pfacet = in%facetlist(f) npolylist(f) = pfacet%numberofpolygons nholelist(f) = pfacet
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #8 from bdubbs at linuxfromscratch dot org 2010-05-16 05:55 --- Created an attachment (id=20671) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20671action=view) Linux kernel configuration that fails with gcc-4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
