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

RE: Internal Compiler Error

The best way to handle this issue is to submit a bugzilla bug-request with a small test case that will replicate the internal error. Thanks, Balaji V. Iyer. > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > tanle > Sent: Monday, December 24

Re: internal compiler error using lambda and this

On Sun, 26 Aug 2012, Gerald Pfeifer wrote: > I tried this with a current snapshot of what will become GCC 4.8.0 > in several months, and now get this: > > $ cat x.cc > auto foo = [&](int a) { return a > this->b; }; > > $ g++ x.cc > x.cc:1:6: error: 'foo' does not name a type >auto foo

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 what

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 several months,

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); assert(d< 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

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

.c:1950 and some other problems..I really need to fix those...  - 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: Fri, 10 Se

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

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 the same > error. > Howe

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/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c >>> >>> bug.c: In funct

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: In function ‘cond_assign_les0’: >> bug.c:1

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_cond, at flow.c:3486 Wh

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

Except if I'm mistaken, force_reg will generally call gen_reg_rtx which does check for those two flags internally (via can_create_pseudo_p). So you should not have that error in this case. I suggest you use a debug_rtx on the operand that's a problem, and first check if gen_reg_rtx is used to crea

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

Thank you for your advice. Yes. I checked the MD file and relative machine.h/.c, there are some places which call the ''force_reg' unconditionally. I modified the it in "movm" insn pattern, the error still exists. And I also check the mips/arm, they also call 'force_reg' unconditional in some plac

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_PSEUDO_REGISTER. Does this me

RE: internal compiler error: Segmentation fault

Hi, Kai, This is what you want, with -dH. If you need further information, please let me know. Finch. . . (8b8.8bc): Break instruction exception - code 8003 (first chance) *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!DbgB

RE: internal compiler error: Segmentation fault

Hi, "J. Finch" wrote on 10.01.2008 16:31:38: Thank you very much for your dumps, but you should use on runtime the option '-dH' option to enforce that you reach the point, where the exception is caused. > stack before and after segmentation fault is as: > > > .. > .. > ntdll!KiUserAp

RE: internal compiler error: Segmentation fault

Hi, stack before and after segmentation fault is as: .. .. ntdll!KiUserApcDispatcher+0x15: `77ef30a5 488bcc mov rcx,rsp 0:000> p ntdll!KiUserApcDispatcher+0x18: `77ef30a8 b201mov dl,1 0:000> k Child-SP RetAddr Call Site 0

RE: internal compiler error: Segmentation fault

> > This looks fine. What is the call stack looks like? And how does the > function calling ntdll looks like? > I think, you should step on an "int 3". Because you simply debug the > exception handling routine itself. > Hi, Kai: I attach the stack in the following: C:\temp\fortran>cdb gfo

RE: internal compiler error: Segmentation fault

Hi, "J. Finch" wrote on 10.01.2008 15:23:56: > > on the issue as stated in the subject regarding x86_64-pc-mingw64, I > have downloaded MS debugger as suggested by FX, and I attach the > logs where command "p" is stepping. > > fortran Program, c.f90, for test, one statement only > [program beg

Re: internal compiler error: Segmentation fault

> To have a better chance to find the issue could you anwser these question? I'll let J. answer these himself, since I have no direct experience of the bug myself (no Win64 machine), but... > a) Does this happens on a cross compiler, too? I doubt it, since he sees the bug even on trivial program

Re: internal compiler error: Segmentation fault

> [for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort thread > starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html] > > > Gcc gets the similar problem. It only works without optimization. > It seems not a problem with gfortran. > > OK, then it'd be more appropriate to ask

Re: internal compiler error: Segmentation fault

[for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort thread starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html] > Gcc gets the similar problem. It only works without optimization. It seems > not a problem with gfortran. OK, then it'd be more appropriate to ask the mingw m

Re: internal compiler error when build toolchains using gcc 4.1.2

马骅 wrote: I thought it may be a bug for gcc 4.1.2. Please don't top-post. On Nov 15, 2007 11:11 AM, Tim Prince <[EMAIL PROTECTED]> wrote: 马骅 wrote: hi, I try to build toolchains using buildroot. but when compile the busybox, an internel compiler error show. If you have questions about th

Re: internal compiler error when build toolchains using gcc 4.1.2

I thought it may be a bug for gcc 4.1.2. On Nov 15, 2007 11:11 AM, Tim Prince <[EMAIL PROTECTED]> wrote: > 马骅 wrote: > > hi, > > I try to build toolchains using buildroot. but when compile the > > busybox, an internel compiler error show. > > > If you have questions about the advice gcc gave you

Re: internal compiler error when build toolchains using gcc 4.1.2

马骅 wrote: > hi, > I try to build toolchains using buildroot. but when compile the > busybox, an internel compiler error show. > If you have questions about the advice gcc gave you, gcc-help mail list is the place.

Re: internal compiler error when compile busybox 1.1.3 using buildroot in cygwin

Hi, Please reply to the list also and not only to me . On Nov 13, 2007 2:38 PM, 马骅 <[EMAIL PROTECTED]> wrote: > The target platform is arm, gcc version is 4.0.3, > binutils-2.17.50.0.8, uClibc-0.9.28. You might need to use a newer version of the compiler. The current release series supported by

Re: internal compiler error when compile busybox 1.1.3 using buildroot in cygwin

Hi, On Nov 13, 2007 2:29 PM, 马骅 <[EMAIL PROTECTED]> wrote: > hi , when I try to compile the busybox 1.1.3 using buildroot in cygwin. > an internal compiler error happens. > Could any one give a help on this? > > LINK busybox_unstripped > /home/mahua/opt/armbuild26_v0 /build_arm/busybox- > 1

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> From: James E Wilson <[EMAIL PROTECTED]> >> On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: >> Thanks. After going through the code, it's even further not clear why >> STRING_CST string literal data references treated differently than >> static const char array literal data references to begin wi

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: > Thanks. After going through the code, it's even further not clear why > STRING_CST string literal data references treated differently than > static const char array literal data references to begin with? > Why is this necessary? Why is what necessa

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

On Fri, 2005-04-22 at 15:56, Paul Schlie wrote: > - Why are string literal character arrays not constructed and expanded as > character array literals are? They are constructed and expanded differently, because, obviously, they are different things. I don't understand the point of this question

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> From: James E Wilson <[EMAIL PROTECTED]> >> - One of the things that's been eluding me, is that I can't seem to find >> where literal string constant mem references aren't being properly >> declared and/or preserved as READONLY/unchanging references, resulting >> in MEM_READONLY_P failing t

Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

Martin Koegler wrote: arg 1 >> So, how to change this function? As a MEM_EXPR may only be a DECL or a COMPONENT_REF, storing a indriect_ref of a plus_expr is also not valid. This is, why I had to change the other functions. There is a var_decl here inside the indirect_ref. Will using

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

Paul Schlie wrote: - Might it be possible to introduce and use by convention a new macro which will always wrap a new pointer in a mem expression with attributes copied from the previous mem/symbol's reference enforced? This is already an easy function call. I don't see how adding a macro mak

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> James E Wilson wrote: > ... > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to stack > slots may not have MEM_EXPR set, but then

Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

Martin, I think that the AVR people would very much appreciate if you would report occasionally on your progresses concerning your realization of the different address space issue on your personal HC05 port. (In my opionion, the lack for support of different memory spaces is the key weakness of

Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

On Wed, Apr 20, 2005 at 06:42:08PM -0700, James E Wilson wrote: > Martin Koegler wrote: > > Placing variables in a specfic section is only a part of the problem. > > I am aware of that. There are already many targets that have special > handling for section attributes, that result in different co

Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

Martin Koegler wrote: > Placing variables in a specfic section is only a part of the problem. I am aware of that. There are already many targets that have special handling for section attributes, that result in different code being generated when a section attribute is present. Mostly these hav

Re: internal compiler error at dwarf2out.c:8362

Am Dienstag, 19. April 2005 00:30 schrieb James E Wilson: > Björn Haase wrote: > > In case that one should not use machine specific atttributes, *is* there > > a standard way for GCC how to implement different address spaces? > > Use section attributes to force functions/variables into different >

different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

James E Wilson wrote: >Björn Haase wrote: >>In case that one should not use machine specific atttributes, *is* >>there a standard way for GCC how to implement different address spaces? > >Use section attributes to force functions/variables into different sections, >and then use linker scripts t

Re: internal compiler error at dwarf2out.c:8362

Martin Koegler wrote: I added to the i386 version the following code (using a unmodified gcc for the rest): With this change, I can reproduce the problem. I noticed that I get a failure for all types, not just array types. This is different than what you described earlier, but perhaps the differe

Re: internal compiler error at dwarf2out.c:8362

Björn Haase wrote: In case that one should not use machine specific atttributes, *is* there a standard way for GCC how to implement different address spaces? Use section attributes to force functions/variables into different sections, and then use linker scripts to place different sections into

Re: internal compiler error at dwarf2out.c:8362

James E Wilson wrote >You shouldn't be trying to build your own types in a machine dependent >attribute handler function. The compiler's type system is determined by >front-ends mainly, and some middle-end infrastructure, and isn't your domain >to mess with. This stuff is subject to change, at

Re: internal compiler error at dwarf2out.c:8362

On Thu, Apr 14, 2005 at 03:02:36PM -0700, James E Wilson wrote: > Martin Koegler wrote: > >I changed the attribute handler to only return NULL_TREE in any case, but > >the result is still the same (using the same gcc core). > > But you are still creating the types in the attribute function right?

Re: internal compiler error at dwarf2out.c:8362

James E Wilson wrote: I tried grepping the sources, and I see this same code appears in the avr and ip2k ports. That gives me a way to try to reproduce the problem with FSF sources. Avr doesn't support DWARF2, and ip2k is being obsoleted because it is unmaintained. As a side note, the AVR por

Re: internal compiler error at dwarf2out.c:8362

Martin Koegler wrote: I changed the attribute handler to only return NULL_TREE in any case, but the result is still the same (using the same gcc core). But you are still creating the types in the attribute function right? If so, that is probably why you still have a problem. You mentioned that th

Re: internal compiler error at dwarf2out.c:8362

On Wed, Apr 13, 2005 at 01:55:07PM -0700, James E Wilson wrote: > Martin Koegler wrote: > > tree type = TREE_TYPE (*node); > > tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type)); > > tree newtype = build_type_attribute_variant (type, attr); > > TYPE_MAIN_

Re: internal compiler error at dwarf2out.c:8362

Martin Koegler wrote: tree type = TREE_TYPE (*node); tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type)); tree newtype = build_type_attribute_variant (type, attr); TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type); TREE_TYPE (*node) = ne