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
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
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
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
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
(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.)
---
Note that crash only happens when using -g
Peter
-Original Message-
From: gcc-bugs-ow...@gcc.gnu.org [mailto:gcc-bugs-ow...@gcc.gnu.org] On Behalf
Of Foelsche, Peter
Sent: Friday, January 19, 2018 16:06
To: gcc-bugs@gcc.gnu.org
Subject: FW: internal compiler error: Segmentation fault
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,
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
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 = [](int
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,
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);
On 10 December 2010 00:40, Nathan Ridge wrote:
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This mailing list is not the right way to report bugs, you should have
followed the instructions in the output you
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 Sep 2010 20:38:58 +
[licensing dealt
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, 11 Sep 2010 08:48:08 +
I kind of suspect
Jay K jay.kr...@cornell.edu 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
On 9/10/2010 11:08 AM, Ian Lance Taylor wrote:
Jay Kjay.kr...@cornell.edu 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
Date: Fri, 10 Sep 2010 11:17:59 -0400
From: de...@adacore.com
To: i...@google.com
CC: jay.kr...@cornell.edu; gcc@gcc.gnu.org
Subject: 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
[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
On Fri, Sep 3, 2010 at 09:00, Anders Furuhed anders.furu...@pantor.com 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
Boris Boesler baem...@gmx.de 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
Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor:
Boris Boesler baem...@gmx.de 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’:
Boris Boesler baem...@gmx.de writes:
Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor:
Boris Boesler baem...@gmx.de 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
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
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 mean
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
G'Day Prof. Peter Morgan
This is Jason Zhang from RSES ANU. While I was recompiling the GAMIT due to
change of my laptop (x-86-64), I encounterred an internal compiling bug which
occurs when doing
gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash
tssum.f
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 begin]
end
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\fortrancdb gfortran
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:
..
..
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 -
[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
[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
马骅 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 the
马骅 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.
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, gcc-help
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-
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 the
Michael Abbott wrote:
../sysdeps/generic/s_fmax.c: In function `__fmax':
../sysdeps/generic/s_fmax.c:28: internal compiler error: in
elim_reg_cond, at flow.c:3328
This looks the same as PR 15068 for which there is already a fix. You
can get the patch from the PR. The PR also indicates that
On Sep 28, 2005, at 10:09 AM, Alexander Stepanov wrote:
Hello,
I've got this strange internal error in gcc:
I don't have a gcc 3.4 or greater at hand now. Can anyone test this
code
against a newer gcc and report a bug normal way if confirmed?
I filed it as PR 24103:
This is a multi-part message in MIME format.
--=_NextPart_000_0035_01C5906D.A0EF4EC0
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
GCC Version: 4.0.1
System Type: Windows ME
Options given when GCC was configured/built: arm-elf-gcc -v
Complete
Mark Weyer [EMAIL PROTECTED] wrote:
Command:
gcc bug.cpp
Output (indented):
bug.cpp: In function `int _ ()':
bug.cpp:1: parse error before `0'
bug.cpp:1: Internal error #122.
bug.cpp:1: Internal compiler error in finish_function, at
../gcc/cp/decl.c:14422
Please submit a
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 necessary?
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 with?
Why
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
Martin Koegler wrote:
indirect_ref 0xb7ed82c0
arg 0 plus_expr 0xb7ee81d4
arg 0 var_decl 0xb7f2506c D.1314 type pointer_type 0xb7ee96c0
arg 1 integer_cst 0xb7f4f978 constant invariant 20
So, how to change this function? As a MEM_EXPR may only be a DECL or a
COMPONENT_REF,
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 to identify
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 code
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
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 they
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
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 to place
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
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
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
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?
If
56 matches
Mail list logo
