Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

gi?id=110926 . Thanks, Andrew > > > > > > > > To quote: > > > > > > > > during RTL pass: split1 > > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function > > > > 'matmul_i1_avx512f&

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

ask, at > > > config/i386/i386.cc:19460 > > > 1781 | } > > >| ^ > > > during RTL pass: split1 > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function > > > 'matmul_i2_avx512f': > > > /h

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

I guess --enable-checking=yes,rtl,extra is key to reproduce the issue? > > > > To quote: > > > > during RTL pass: split1 > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function > > 'matmul_i1_avx512f': > > /home/toon/compil

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

ed/matmul_i1.c: In function > 'matmul_i1_avx512f': > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at config/i386/i386.cc:19460 1781 | } | ^ during RTL pass: split1 /home/toon/compilers/gcc/libgfo

Re: GCC / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function

Thanks. An internal compiler error is always a problem with the compiler itself. I submitted this to our bug tracker (Bugzilla) as Problem Report 96712 on your behalf. Follow it by looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96712 Kind regards, Toon. On 8/19/20 4:22 PM, Bernd

Re: GCC / GFortran (9.3.0; Cygwin 64 and Ubuntu) Internal Compiler Error on NINT() Function

On Wed, Aug 19, 2020 at 10:34 AM Bernd Eggen via Gcc wrote: > > Hello, > > I realised when I created the small code snippet I accidentally put the > variable "m" in the default integer declaration, I checked it and moving it > (to kind=16) does not make a difference either. > > I also checked on U

Re: GCC / GFortran (9.3.0; Cygwin 64 and Ubuntu) Internal Compiler Error on NINT() Function

the same error message / behaviour. I re-attach the corrected f90 file, which also as a slightly improved loop exit condition. Best wishes, Bernd On Wed, 19 Aug 2020 at 15:22, Bernd Eggen wrote: > Hello, > > I've come across an internal compiler error (in GFortran), concern

Re: GCC / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function

On Wed, 19 Aug 2020 at 15:24, Bernd Eggen via Gcc wrote: > > Hello, > > I've come across an internal compiler error (in GFortran), concerning the > function NINT(), Then you should be reporting it to Bugzilla, not to this mailing list. > Please submit a full bug repo

GCC / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function

Hello, I've come across an internal compiler error (in GFortran), concerning the function NINT(), I attach a very simple source code that illustrates the error. Essentially I am working with 16-byte integers, and there seems no way to ensure that NINT() returns the correct precision intege

Re: [gcc 10-20190728] internal compiler error: in speculative_call_info, at cgraph.c:1114

On (07/30/19 14:12), Sergey Senozhatsky wrote: > On (07/29/19 09:42), Jonathan Wakely wrote: > > Please don't cross-post to te gcc@ and gcc-bugs@ lists, that's never > > appropriate. > > So is top-posing ;) D'oh... s/posing/posting/ Will keep in mind next time that gcc team prefers bugzilla.

Re: [gcc 10-20190728] internal compiler error: in speculative_call_info, at cgraph.c:1114

On (07/29/19 09:42), Jonathan Wakely wrote: > Please don't cross-post to te gcc@ and gcc-bugs@ lists, that's never > appropriate. So is top-posing ;) > The gcc@ list is not for reporting bugs, and the > gcc-bugs@ list is for automated emails sent from our Bugzilla > database, also not for reporti

Re: [gcc 10-20190728] internal compiler error: in speculative_call_info, at cgraph.c:1114

hanks. On Mon, 29 Jul 2019 at 02:37, Sergey Senozhatsky wrote: > > Hi, > > While compiling gcc-10-20190728 snapshot: > > src/gcc-10-20190728/gcc/tree-ssa-sccvn.c:7323:1: internal compiler error: in > speculative_call_info, at cgraph.c:1114 > 7323 | }

[gcc 10-20190728] internal compiler error: in speculative_call_info, at cgraph.c:1114

Hi, While compiling gcc-10-20190728 snapshot: src/gcc-10-20190728/gcc/tree-ssa-sccvn.c:7323:1: internal compiler error: in speculative_call_info, at cgraph.c:1114 7323 | } | ^ 0x5d34b9 cgraph_edge::speculative_call_info(cgraph_edge*&, cgraph_edge*&, ipa_ref*&) /home/

Re: Internal compiler error building libstdc++ for vax

On 04/10/2018 01:27 PM, Maciej W. Rozycki wrote: > On Sun, 8 Apr 2018, Jeff Law wrote: > >> I think you need to go back to my earlier reply and read it carefully. >> In particular, you need an insn where the label_ref and pc are swapped. > > Ouch, there are no reversed interlocked branch instruc

Re: Internal compiler error building libstdc++ for vax

On Sun, 8 Apr 2018, Jeff Law wrote: > I think you need to go back to my earlier reply and read it carefully. > In particular, you need an insn where the label_ref and pc are swapped. Ouch, there are no reversed interlocked branch instructions in the VAX ISA, so these would have to branch around

Re: Internal compiler error building libstdc++ for vax

On 04/02/2018 10:15 AM, co...@sdf.org wrote: > It turns out (all from krister, I am still totally lost) that it is not > failing for this specific reason in this case. > > Rather, the attached patch from krister fixes it, saying that gcc > wants to change the label and then doesn't recognise the n

Re: Internal compiler error building libstdc++ for vax

It turns out (all from krister, I am still totally lost) that it is not failing for this specific reason in this case. Rather, the attached patch from krister fixes it, saying that gcc wants to change the label and then doesn't recognise the new insn thinking the memory_operand predicate is not sa

Re: Internal compiler error building libstdc++ for vax

On 03/19/2018 03:46 PM, co...@sdf.org wrote: > (updating) > krister found a better hack patch which explains what the problem is, > adding a useless move at the end of the instruction, so the label is > not the last instruction. > > (And, in the problem code, the last instruction in the function.)

Re: Internal compiler error building libstdc++ for vax

(updating) krister found a better hack patch which explains what the problem is, adding a useless move at the end of the instruction, so the label is not the last instruction. (And, in the problem code, the last instruction in the function.) --- a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md

Internal compiler error building libstdc++ for vax

Hi folks, netbsd's copy of GCC differs enough that it fails elsewhere with gcc-trunk, but the problematic code is upstream. updating netbsd to gcc 6.4.0, I get an internal compiler error building libstdc++. (Long version: http://gnats.netbsd.org/53039) Short version: test.cc: In function

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On Tue, 2017-03-21 08:46:50 -0600, Jeff Law wrote: > On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: > > When building a cross-gcc using config_list.mk using r245361 (as both, > > a freshly built `build' compiler and as sources for the > > cross-compiler), my build robot fails (see > > http://too

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: Hi! When building a cross-gcc using config_list.mk using r245361 (as both, a freshly built `build' compiler and as sources for the cross-compiler), my build robot fails (see http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565). S

[BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault 0xaf7fdf crash_signal /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333 0x6739b3 lookup_page_table_entry /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635 0x6739b3 ggc_set

Re: GCC 4.9 internal compiler error

On Mon, Sep 29, 2014 at 11:43:47AM +0400, Игорь Пашев wrote: > Hi all! > > It was found that OA fails to build with GCC 4.9 on amd64 [1] > I can confirm this with r3094 on bare metal too. > > # gcc --version > gcc-4.9.real (Debian 4.9.1-14) 4.9.1 > Copyright (C) 2014 Free Software Foundation, Inc

GCC 4.9 internal compiler error

27;T* > OpenAxiom::Memory::Factory::make(const Args& ...) [with Args = > {std::vector OpenAxiom::Sexpr::Syntax*> >, bool}; T = OpenAxiom::Sexpr::ListSyntax]': > ../../../src/syntax/sexpr.cc:341:37: required from here > ../../x86_64-pc-linux-gnu/include/open-axiom/stora

Internal compiler error with -O2 and optimize("O0")

Hi, -O2 command line option and optimize("O0") (#pragma GCC optimize ("O0") or __attribute__((optimize("O0")))) sometimes leads to internal compiler error with trace: internal compiler error: in parm_ref_data_preserved_p, at ipa-prop.c:740 } ^ 0x898982b ipcp_gene

ToT Build failure (internal compiler error: in phi_nodes_ptr)

;&5 conftest.c: In function 'main': conftest.c:16:1: internal compiler error: in phi_nodes_ptr, at tree-flow-inline.h:458 } ^ 0x73e403 phi_nodes_ptr /local/home/sellcey/nightly2/src/gcc/gcc/tree-flow-inline.h:458 0x73e403 gsi_start_phis(basic_block_def*) /local/home/sel

RE: Internal Compiler Error

ay, December 24, 2012 11:44 AM > To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org > Subject: Internal Compiler Error > > Could you explain for you about "Internal Compiler Error"? > I am building the Linux kernel for microbalze (Atlys Board), there are some > err

Internal Compiler Error

Could you explain for you about "Internal Compiler Error"? I am building the Linux kernel for microbalze (Atlys Board), there are some errors as: fs/ext2/super.c: In function 'ext2_fill_super': fs/ext2/super.c:1144:1: internal compiler error: in reload, at reload1.c:1059

Re: internal compiler error using lambda and this

x27;foo' does not name a type >auto foo = [&](int a) { return a > this->b; }; > ^ It has been pointed out to me (Thanks!) that this requires -std=c++0x to show the internal compiler error. I reproduced this with current development sources and reported http://gc

Re: internal compiler error using lambda and this

On 08/26/2012 01:09 AM, Gerald Pfeifer wrote: On Tue, 29 May 2012, Andreas Karrenbauer wrote: To whom it may concern: Please find a small code example which causes an internal compiler error with g++-4.7 (opensuse): Thanks for the report, Andreas. I tried this with a current snapshot of

Re: internal compiler error using lambda and this

On Tue, 29 May 2012, Andreas Karrenbauer wrote: > To whom it may concern: > > Please find a small code example which causes an internal compiler error with > g++-4.7 (opensuse): Thanks for the report, Andreas. I tried this with a current snapshot of what will become GCC 4.8.0 in se

internal compiler error in find_costs_and_classes

Hi, I did some iwmmxt intrinsic test for mainline gcc with this check-in r190511 | nickc | 2012-08-19 15:11:35 +0800 (Sun, 19 Aug 2012) | 3 lines PR target/54306 * config/arm/mmintrin.h: Remove spurious #endif. and encountered an internal compiler error for this simple case

internal compiler error using lambda and this

To whom it may concern: Please find a small code example which causes an internal compiler error with g++-4.7 (opensuse): Best regards, Andreas Karrenbauer $ cat bug_g++.cc auto foo = [&](int a) { return a > this->b; }; int main() { return 0; } $ g++-4.7 -v -Wall -g -std=c++0x

Re: [gimplefe] Ran into a internal compiler error

On Tue, Sep 20, 2011 at 10:48 PM, Diego Novillo wrote: > On 11-09-19 23:32 , Sandeep Soni wrote: > >> It gives me a internal compiler error saying: >> gimple1: internal compiler error: tree check: expected >> identifier_node, have var_decl in gimple_symtab_entry_hash

Re: [gimplefe] Ran into a internal compiler error

On 11-09-19 23:32 , Sandeep Soni wrote: It gives me a internal compiler error saying: gimple1: internal compiler error: tree check: expected identifier_node, have var_decl in gimple_symtab_entry_hash As Balaji said, the problem is that you need to pass DECL_NAME(base->decl)

RE: [gimplefe] Ran into a internal compiler error

t;decl)); Thanks, Balaji V. Iyer. -Original Message- From: Sandeep Soni [mailto:soni.sande...@gmail.com] Sent: Monday, September 19, 2011 11:32 PM To: GCC LIST Cc: Diego Novillo Subject: [gimplefe] Ran into a internal compiler error Hi, I was trying to make a symbol table for all the va

[gimplefe] Ran into a internal compiler error

r_gc_root__ = NULL; } - /* Main entry point for the GIMPLE front end. */ void @@ -1402,7 +1446,6 @@ parser_gc_root__ = parser = gp_init (main_input_filename); if (parser->lexer->filename == NULL) return; - gl_lex (parser->lexer); gp_parse (parser); gp_finish (

Re: An internal compiler error when building gcc4.6 using "-flto -fuse-linker-plugin" on Win7 mingw64 target

On 12 September 2011 10:05, PcX wrote: > > > Hi, all > >    I report it to gcc bugzilla > :http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 Then there's no need to also email this list. Discussion of the bug should take place in Bugzilla, not here.

Re: An internal compiler error when building gcc4.6 using "-flto -fuse-linker-plugin" on Win7 mingw64 target

/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lstdc++ -lcloog-isl -lisl -lppl_c -lppl -lgmpxx -lmpc -lmpfr -lgmp -lstdc++ -lz lto1.exe: internal compiler error: in lto_reissue_options, at lto-opts.c:414 Please

An internal compiler error when building gcc4.6 using "-flto -fuse-linker-plugin" on Win7 mingw64 target

Hi, all I report it to gcc bugzilla :http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 When I use mingw64 gcc build gcc4.6.2 20110909 using "-flto -fuse-linker-plugin", an internal compiler erro

Re: Internal compiler error in targhooks.c: default_secondary_reload (ARM/Thumb)

On 04/04/2011 02:34 PM, Matt Fischer wrote: I'm getting an internal compiler error on the following test program: void func(int a, int b, int c, int d, int e, int f, int g, short int h) { assert(a< 100); assert(b< 100); assert(c< 100);

Internal compiler error in targhooks.c: default_secondary_reload (ARM/Thumb)

I'm getting an internal compiler error on the following test program: void func(int a, int b, int c, int d, int e, int f, int g, short int h) { assert(a < 100); assert(b < 100); assert(c < 100); assert(d < 100); assert(e < 100);

Re: internal compiler error in gcc trunk when using std::map

On 10 December 2010 00:40, Nathan Ridge wrote: > > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. This mailing list is not the right way to report bugs, you should have followed the instructions in the output you q

internal compiler error in gcc trunk when using std::map

Hello, I've just build the gcc trunk and tried to compile some code that compiled fine with gcc 4.5. It gave an internal compiler error. I've reduced it to the following minimal test case: #include #include int main() { std::map m; std::pair p; m.insert(p);

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

I have it seemingly working now, much better, thanks for the nudges -- that indeed high id is invalid, and to look again at my GTY use. I don't know if it made the difference but I changed some whitespace to match others, and typedef struct foo_t { ... } foo_t; to typedef struct foo { ... } foo_

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

;VEC" or even use a fixed size and see what happens.. Thanks,  - Jay > From: jay.kr...@cornell.edu > To: i...@google.com > CC: gcc@gcc.gnu.org > Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c > Date: Sat,

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

> I kind of suspect it might be a type mismatch, overwriting part of a tree node configure -enable-checking: ?"Bmr?: In function 'FPrint__xCombine': `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have var_decl in copy_phis_for_bb, at tree-inline

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[licensing dealt with separately] > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def > > 0x412130a8 1093058884 > This is clearly wrong, though I have no idea what caused it. > > Is it valid for uids to be so high? > No. Thanks, that helps. > From your description, you've

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

ks a chance to not "like" me and not help me. I'll address the technical part separately. Thanks,  - Jay > Date: Fri, 10 Sep 2010 11:17:59 -0400 > From: de...@adacore.com > To: i...@google.com > CC: jay.kr...@cornell.edu; gcc

Re: internal compiler error: in referenced_var_lookup, at tree-dfa.c

On 9/10/2010 11:08 AM, Ian Lance Taylor wrote: Jay K writes: That uses process boundaries to avoid GPL crossing into BSDish licensed code. So maybe you don't want to help me. Understood. Note that different people have different opinions as to whether a process boundary means that your code

Re: internal compiler error: in referenced_var_lookup, at tree-dfa.c

Jay K writes: > That uses process boundaries to avoid GPL crossing into BSDish licensed code. > So maybe you don't want to help me. Understood. Note that different people have different opinions as to whether a process boundary means that your code is not a derived work. Not that we should get

internal compiler error: in referenced_var_lookup, at tree-dfa.c

ccesses by offseting pointers and casting. We do our own layout earlier. Not great, but that's how it is. Currently we use gcc 4.5.1. When I enable inlining on some architectures, e.g. Macosx/x86, much code yields: ../FPrint.m3: In function 'FPrint__xCombine': ../FPrint.m3:25:0: in

Re: Internal compiler error, gimplify.c:505. File a report?

On Fri, Sep 3, 2010 at 09:00, Anders Furuhed wrote: > Hi, > > I get an internal compiler error from the assert in gimplify.c:505 when > trying out gcc-4.5.1 on RHEL 5.5 + mpc-0.8.2,mpfr-3.0.0,gmp-5.0.1. > Checking out and building from gcc-4_5-branch (r163774) results in th

Internal compiler error, gimplify.c:505. File a report?

Hi, I get an internal compiler error from the assert in gimplify.c:505 when trying out gcc-4.5.1 on RHEL 5.5 + mpc-0.8.2,mpfr-3.0.0,gmp-5.0.1. Checking out and building from gcc-4_5-branch (r163774) results in the same error. However, trunk (r163797) passes. Would this be a duplicate or should

Re: internal compiler error in elim_reg_cond

Boris Boesler writes: > Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor: > >> Boris Boesler writes: >> >>> I get an internal compiler error with gcc-4.2.1 and my own back-end >>> when I support conditional execution: >>> >>> ../build/

Re: internal compiler error in elim_reg_cond

Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor: > Boris Boesler writes: > >> I get an internal compiler error with gcc-4.2.1 and my own back-end >> when I support conditional execution: >> >> ../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c >> >> bug.c

Re: internal compiler error in elim_reg_cond

Boris Boesler writes: > I get an internal compiler error with gcc-4.2.1 and my own back-end > when I support conditional execution: > > ../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c > > bug.c: In function ‘cond_assign_les0’: > bug.c:13: internal compiler error: in elim_reg

internal compiler error in elim_reg_cond

I get an internal compiler error with gcc-4.2.1 and my own back-end when I support conditional execution: ../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c bug.c: In function ‘cond_assign_les0’: bug.c:13: internal compiler error: in elim_reg_cond, at flow.c:3486 The test C file "bug.c"

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

l 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 ) bkfco

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

pe        type            align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20 >            pointer_to_this > >        QI >        size >        unit size >        align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000> >    public external QI file bkfconv.f90 li

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

size align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000> public external QI file bkfconv.f90 line 7712 col 0 align 8> > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000> public external QI file

internal compiler error compiling gmp/get_d/gmpn_get_d for alpha-dec-vms

lo get_d.c  alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp -DOPERATION_get_d -g -O2 -c get_d.c -o get_d.obj get_d.c: In function '__gmpn_get_d': get_d.c:490:1: internal compiler error: in compute_frame_pointer_to

gcc-4.5.0 internal compiler error on alpha-dec-vms compiling libiberty/regex.c without -mbwx

/f:DI 109 [ pfrom ]) 0) > (const_int 5 [0x5]))) -1 (nil)) > /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in > extract_insn, at recog.c:2103 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make: *** [regex.o]

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

> 2010/4/29 Jan Hubicka : > >> Well, we'd then need to re-architect the symbol merging and > >> LTO unit read-in to properly honor linking semantics (drop > >> a LTO unit from an archive if it doesn't resolve any unresolved > >> symbols).  I don't know how easy that will be, but it shouldn't > >> b

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010/4/29 Jan Hubicka : >> Well, we'd then need to re-architect the symbol merging and >> LTO unit read-in to properly honor linking semantics (drop >> a LTO unit from an archive if it doesn't resolve any unresolved >> symbols).  I don't know how easy that will be, but it shouldn't >> be impossible

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

Richard Guenther writes: > Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible a

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

> Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible at least. We also should ke

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

On Thu, Apr 29, 2010 at 11:19 AM, Steven Bosscher wrote: > On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther > wrote: >> Yes - that would be basically a linker plugin without plugin support. >> And I'd go even further and have LD provide a complete symbol >> resolution set like we get from the g

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther wrote: > Yes - that would be basically a linker plugin without plugin support. > And I'd go even further and have LD provide a complete symbol > resolution set like we get from the gold linker-plugin. > > That wouldn't help for old or non-gnu LDs

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

On Thu, Apr 29, 2010 at 6:11 AM, Dave Korn wrote: > On 26/04/2010 10:46, Richard Guenther wrote: >> On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn wrote: > >>>  If I understand correctly, what we farm out to gold/lto-plugin is the task >>> of identifying a) which archive members are required to be pul

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn wrote: > On 25/04/2010 23:16, Steven Bosscher wrote: >> On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote: >> >>>  Is there a PR open about this, or any notes anywhere?  Being as I use a >>> non-ELF platform and so gold is not an option, I'd be pleased to

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On 25/04/2010 23:16, Steven Bosscher wrote: > On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote: > >> Is there a PR open about this, or any notes anywhere? Being as I use a >> non-ELF platform and so gold is not an option, I'd be pleased to help with >> making this work. > > See http://gcc.gnu.

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote: >  Is there a PR open about this, or any notes anywhere?  Being as I use a > non-ELF platform and so gold is not an option, I'd be pleased to help with > making this work. See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some firs

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On 25/04/2010 21:41, Richard Guenther wrote: > I'm somewhat uncomfortable that we have the two paths into LTO, > by using collect2 or the linker plugin. Unfortunately the linker-plugin > is currently the only path that supports LTOing static libs. As soon > as that issue is solved we should IMHO

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Sun, Apr 25, 2010 at 9:37 PM, Steven Bosscher wrote: > On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther > wrote: >> >> No, gold should choose a single prevailing definition.  The issue is that >> gold and the linker-plugin seem to be unmaintained. > > Looking at the binutils list, there seems

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther wrote: > > No, gold should choose a single prevailing definition.  The issue is that > gold and the linker-plugin seem to be unmaintained. Looking at the binutils list, there seems to be a lot of gold patching going on. Why do you believe it is un

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Sun, Apr 25, 2010 at 1:24 PM, Toon Moene wrote: > Richard Guenther wrote: > >> On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote: > >>> lto-symtab.c:549: >>> >>>   524 >>>   525 /* Helper to process the decl chain for the symbol table entry >>> *SLOT. >>>  */ >>>   526 >>>   527 static int >>>

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

Richard Guenther wrote: On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote: lto-symtab.c:549: 524 525 /* Helper to process the decl chain for the symbol table entry *SLOT. */ 526 527 static int 528 lto_symtab_merge_decls_1 (void **slot, void *data ATTRIBUTE_UNUSED)

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote: > While compiling our Weather Forecasting code with the latest trunk, I got > the following (don't know how long this has been a problem, as I haven't > tried -flto recently): > > lto1: internal compiler error: in lto

lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

While compiling our Weather Forecasting code with the latest trunk, I got the following (don't know how long this has been a problem, as I haven't tried -flto recently): lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549 Please submit a full bug re

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 04/19/2010 02:17 PM, Jonathan Wakely wrote: On 19 April 2010 08:20, Justin P. Mattock wrote: On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was fa

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 19 April 2010 08:20, Justin P. Mattock wrote: > On 04/18/2010 11:57 PM, Jie Zhang wrote: >> >> On 04/19/2010 02:43 PM, Justin P. Mattock wrote: >>> >>> I couldn't resist..(had to play), >>> anyways I looked through the reports >>> but didn't see anything that was >>> familiar. so I went and crea

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 04/18/2010 11:57 PM, Jie Zhang wrote: On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks.

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 04/19/2010 02:43 PM, Justin P. Mattock wrote: I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Thanks. Please add a preprocessed source file so pe

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 04/18/2010 10:35 PM, Ben Gamari wrote: On Sun, 18 Apr 2010 21:19:19 -0700, Justin Mattock wrote: so far I've compiled most of the system (glibc,Xserver,etc..) and not really anything has crashed and burned except for the kernel: You are using a pre-release compiler. It should be no surpri

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On Sun, 18 Apr 2010 21:19:19 -0700, Justin Mattock wrote: > so far I've compiled most of the system > (glibc,Xserver,etc..) > and not really anything has crashed and burned > except for the kernel: > You are using a pre-release compiler. It should be no surprise that it chokes on the kernel. You

Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

On 04/19/2010 12:19 PM, Justin Mattock wrote: so far I've compiled most of the system (glibc,Xserver,etc..) and not really anything has crashed and burned except for the kernel: kernel/rtmutex.c: At top level: kernel/rtmutex.c:1138:1: internal compiler erro

gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error

so far I've compiled most of the system (glibc,Xserver,etc..) and not really anything has crashed and burned except for the kernel: kernel/rtmutex.c: At top level: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009 Please sub

internal compiler error: in simplify_subreg, at simplify-rtx.c:5138

map.o mm/rmap.c: In function 'try_to_unmap_one': mm/rmap.c:860:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5138 Please submit a full bug report, I have tried to find the exact place which introduced this error and at last found out this line of that file: 818

Re: internal compiler error: in reload_combine_note_use, at postreload.c:1093

5/13 Dave Korn : >> daniel tian wrote: >>> I have ported gcc4.0.2  to 32bit RISC chip. But internal compiler >>> error happened: in reload_combine_note_use, at postreload.c:1093 . I >>> tracked the code with insight.  error occurred in "CASE REG", when the

Re: internal compiler error: in reload_combine_note_use, at postreload.c:1093

rce_reg' unconditional in some places. Anything I missed? 2009/5/13 Dave Korn : > daniel tian wrote: >> I have ported gcc4.0.2  to 32bit RISC chip. But internal compiler >> error happened: in reload_combine_note_use, at postreload.c:1093 . I >> tracked the code with insi

Re: internal compiler error: in reload_combine_note_use, at postreload.c:1093

daniel tian wrote: > I have ported gcc4.0.2 to 32bit RISC chip. But internal compiler > error happened: in reload_combine_note_use, at postreload.c:1093 . I > tracked the code with insight. error occurred in "CASE REG", when the > register number is larger than FIRST_PSEU

internal compiler error: in reload_combine_note_use, at postreload.c:1093

I have ported gcc4.0.2 to 32bit RISC chip. But internal compiler error happened: in reload_combine_note_use, at postreload.c:1093 . I tracked the code with insight. error occurred in "CASE REG", when the register number is larger than FIRST_PSEUDO_REGISTER. Does this mean the reloa

Re: Bootstrap on powerpc-linux trunk broken between r145531 and r145540 internal compiler error: in fold_convert, at fold-const.c:2506

number -DHAVE_CC_TLS -o decQuad.o -MT decQuad.o -MD -MP -MF decQuad.dep > -c ../../../../trunk/libgcc/../libdecnumber/decQuad.c > In file included from ../../../../trunk/libgcc/../libdecnumber/decQuad.c:145: > ../../../../trunk/libgcc/../libdecnumber/decBasic.c: In function > 'de

Bootstrap on powerpc-linux trunk broken between r145531 and r145540 internal compiler error: in fold_convert, at fold-const.c:2506

d from ../../../../trunk/libgcc/../libdecnumber/decQuad.c:145: ../../../../trunk/libgcc/../libdecnumber/decBasic.c: In function 'decFiniteMultiply': ../../../../trunk/libgcc/../libdecnumber/decBasic.c:723: internal compiler error: in fold_convert, at fold-const.c:2506 Please submit a full

RE: internal compiler error: Segmentation fault

kernel32!BaseProcessStart 0:000> p ntdll!KiUserApcDispatcher+0x1a: `77ef30aa e861dd callntdll!NtContinue (`77ef0e10) 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a `0022ffa8 000

RE: internal compiler error: Segmentation fault

Child-SP RetAddr Call Site > `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a > `0022ffa8 0000`0000 kernel32!BaseProcessStart > 0:000> p > c.f90: In function 'MAIN__': > c.f90:1: internal compiler error: Segmentation

RE: internal compiler error: Segmentation fault

Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a `0022ffa8 ` kernel32!BaseProcessStart 0:000> p c.f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preproces

  1   2   >