Hi,
I try to change the front-end tree structure of a c/c++ program as a
side effect of execution of a pragma. The operations that are involved
is to walk through in a tree (i.e C block), insertion of a tree
(i.e. statement, block, declaration) in the abstract syntax tree and
deletion of a tree
From: Ulrich Weigand
Erwin Unruh wrote:
I have a problem with delete_output_reload. It sometimes deletes
instructions which are needed. Here an analysis of a recent
case (In a
private version of the S390 port). The original S390 shows
almost the
same reloads, but chooses different
I try to change the front-end tree structure of a c/c++ program as a
side effect of execution of a pragma. The operations that are involved
is to walk through in a tree (i.e C block), insertion of a tree
(i.e. statement, block, declaration) in the abstract syntax tree and
deletion of a tree
Ferad Zyulkyarov writes:
Also, having the opportunity, I would like to ask you if there is any
function to use for deleting a tree (most particularly a statement or
variable declaration tree) or it would be enough to assign it as NULL
(which does not seems to be a gentle solution).
Erwin Unruh wrote:
Sorry, I mislead you. Somehow I did confuse (mem/c:DI (reg:SI 2 2) [0 S8
A8])
with (reg:DI 2). Register 2 is used correctly.
I do not think any reload is inherited in this case.
Ah, right. That did confuse me ;-)
I did find something which might be the real problem.
Le Tue, Dec 05, 2006 at 07:12:08AM -0500, Diego Novillo écrivait/wrote:
Kaveh R. GHAZI wrote on 12/04/06 21:32:
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Paolo Bonzini [EMAIL PROTECTED] writes:
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Note that these two issues (my patch, which by the way was started and
Hello all,
I am working on adding a new data type in gcc under C.
Please tell me, if I don't want to use the debugging info/format in
DBX, but still I want to build gcc in cygwin… what changes should be
made on dbxout.c?
Is it compulsory that I have to provide support in dbxout.c?
Thanks in
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
I'm not sure to follow Diego and I am a bit concerned about other
potential external libraries. Suppose for example that some GCC code
uses an external library like the Parma Polyedral Library
http://www.cs.unipr.it/ppl/ (which is very useful for
RAHUL V R [EMAIL PROTECTED] writes:
I am working on adding a new data type in gcc under C.
Please tell me, if I don't want to use the debugging info/format in
DBX, but still I want to build gcc in cygwin
what changes should be
made on dbxout.c?
Is it compulsory that I have to provide
This all may just be a shakedown problem with MPFR, and maybe it will
stabilize shortly. But it's disturbing that after one undistributed
version became a requirement, we then very shortly stepped up to a new
undistributed version. I think it should be obvious that if we
require an external
Paul Brook [EMAIL PROTECTED] writes:
This all may just be a shakedown problem with MPFR, and maybe it will
stabilize shortly. But it's disturbing that after one undistributed
version became a requirement, we then very shortly stepped up to a new
undistributed version. I think it should
On 05 Dec 2006 07:16:04 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Paul Brook [EMAIL PROTECTED] writes:
This all may just be a shakedown problem with MPFR, and maybe it will
stabilize shortly. But it's disturbing that after one undistributed
version became a requirement, we then
Richard Guenther wrote:
As far as I know both versions are released. What I said was
undistributed, by which I mean: the required version of MPFR is not
on my relatively up to date Fedora system.
It also missed the openSUSE 10.2 schedule (which has the old version
with all patches). So I
On Dec 4, 2006, at 20:19, Howard Hinnant wrote:
If that is the question, I'm afraid your answer is not accurate.
In the example I showed the difference is 2 ulp. The difference
appears to grow with the magnitude of the argument. On my systems,
when the argument is DBL_MAX, the
Hello,
I have a RCM3400 Rabbitcore and I must create a client with this
circuit. I have created a C# file with Visual Studio but I need a
Dynamic C file ( or C file) to program the Rabbit. Then,I must
translate this in Dynamic C language.
How can I do?
BYE.
Naviga e telefona senza limiti
Hi folks.
I have just merged gimple-tuples-branch into mainline.
The memory improvements as of last night are as follows:
-O0: 0.260409%
-O1: 0.828741%
-O2: 0.826724%
These are averages in analyzing about 8000 functions taken from Diego's .i
sandbox. I used the same
Hello,
the message is off-topic here (this is a list about GCC development),
but the answer to your question is easy and short: you should write your
program in C.
Cheers,
Roberto
[EMAIL PROTECTED] wrote:
Hello,
I have a RCM3400 Rabbitcore and I must create a client with this
circuit. I
Snapshot gcc-4.2-20061205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I've been investigating a testsuite failure which shows up with the new
TER implementation, and it appears to be a bug in the code for
expand_builtin_memcpy.
The problem is an array slice of a string constant, which is this case
originates in gfortran.
The source code looks like:
subroutine
Cancel that, it's a local change of mine causing the breakage :)
On 12/5/06, Daniel Berlin [EMAIL PROTECTED] wrote:
Aldy, your tuples change broke teh build on i686-darwin.
I've attached a file that fails, it should fail with a cross compiler.
I've been investigating a testsuite failure which shows up with the new
TER implementation, and it appears to be a bug in the code for
expand_builtin_memcpy.
Does that seem reasonable? or would everyone prefer I get it fixed
before checking in the TER code?
I would prefer you don't
On Dec 5, 2006, at 3:14 AM, Ferad Zyulkyarov wrote:
Also, having the opportunity, I would like to ask you if there is any
function to use for deleting a tree
ggc_free if you _know_ it is free.
On 12/5/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My preference is to check in the TER code which exposes this bug, and
open a PR against the failure with this info. That way we don't lose
track of the problem, and someone can fix it at their leisure. Until
then there will be a testsuite
Hello
I am not sure to understand what if_marked or deletable means in GTY context
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
http://gcc.gnu.org/wiki/Memory_management
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (this should indeed be
possible, since GGC is a mark sweep garbage collector, which delet
individually each dead data).
if_marked and deletable are not what you want; they are two
On Mon, Dec 04, 2006 at 07:51:00PM +, Manuel López-Ibáñez wrote:
Dear Janis,
I am having problems implementing your proposal.
The following testcase should fail with current mainline for everydg-bogus.
It actually passes perfectly :-(. I have tried removingthe dg-warning
tests but
Dear GCC Experts,
I am trying to understand the subtleties of __attribute__((packed)). I
have some code that works on x86, where unaligned accesses work, but
fails on ARM where they do not.
As far as I can see, if I declare a struct with the packed attribute
applied to the whole struct,
On Tuesday 05 December 2006 22:40, Phil Endecott wrote:
Dear GCC Experts,
I am trying to understand the subtleties of __attribute__((packed)). I
have some code that works on x86, where unaligned accesses work, but
fails on ARM where they do not.
As far as I can see, if I declare a struct
On 05/12/06, Janis Johnson [EMAIL PROTECTED] wrote:
On Mon, Dec 04, 2006 at 07:51:00PM +, Manuel López-Ibáñez wrote:
The following testcase should fail with current mainline for everydg-bogus.
It actually passes perfectly :-(. I have tried removingthe dg-warning
tests but then only the
On Tue, Dec 05, 2006 at 11:47:48PM +, Manuel López-Ibáñez wrote:
On 05/12/06, Janis Johnson [EMAIL PROTECTED] wrote: On Mon, Dec 04,
2006 at 07:51:00PM +, Manuel López-Ibáñez wrote: The following
testcase should fail with current mainline for everydg-bogus. It
actually passes
On 12/5/06, Basile STARYNKEVITCH [EMAIL PROTECTED] wrote:
Hello
I am not sure to understand what if_marked or deletable means in GTY context
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
http://gcc.gnu.org/wiki/Memory_management
I want to have a GTY() garbage collected structure such
I'm getting several thousand gfortran testsuite errors with messages
like:
FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll-
all-loops -finline-functions (test for excess errors)
Excess errors:
/Users/gcc-test/programs/gcc/mainline/gcc/testsuite/gfortran.dg/
On Wed, Dec 06, 2006 at 01:11:17AM -0500, Bradley Lucier wrote:
I'm getting several thousand gfortran testsuite errors with messages
like:
FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll-
all-loops -finline-functions (test for excess errors)
Excess errors:
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-05 08:25 ---
Duuuhhh!
Erik, if you have a moment, could you see if you can understand where the
extra free comes from?
That was the whole point, wasn't it? :-)
So the full patch will modify allocatable_function_1.f90 to
--- Comment #4 from valentin dot longchamp at gmail dot com 2006-12-05
09:04 ---
I've upgraded my toolchain (it is automatically built by my embedded Linux
development framework, openembedded) and the problem is here again. The version
used for gcc is 4.1.1.
Here are the last
Failure to relink libjvm.la
xgcc: /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/lib/libgcj.sl: No
such file or directory
libtool: install: error: relink `libjvm.la' with the above command before
installing it
I tracked it down to an install sequence issue.
Makefile.in in the libjava
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-05 09:39 ---
Created an attachment (id=12746)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12746action=view)
Patch and testcase for the PR
This regtests OK on Cygwin_NT/PIV. I will submit it tonight.
Paul
--
pault at
Return type of implicitly declared functions
Return type of an implicitly declared function is supposed to be int (signed
that is)
//temp.c
f(int i)
{
if (g(i) 0)
printf(dead);
}
the return type of g(int) is int (normally)
but when the parameter list of an implicitly
--- Comment #1 from bhaskar dot priya at wipro dot com 2006-12-05 11:17
---
Created an attachment (id=12747)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12747action=view)
lineid info for implicit declaration (int)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30072
--- Comment #2 from bhaskar dot priya at wipro dot com 2006-12-05 11:17
---
Created an attachment (id=12748)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12748action=view)
Lineidinfo file for unsigned int implicit declaration
--
In the following program the size of the array a is exeeded not of t%b, but
gfortran claims otherwise:
Fortran runtime error: Array reference out of bounds for array 't', upper bound
of dimension 3 exceeded (in file 'test.f90', at line 10)
(That gfortran shows t rather than b or t%b is PR29800
This patch:
2006-12-02 H.J. Lu [EMAIL PROTECTED]
PR target/30040
* config/i386/driver-i386.c: Include coretypes.h and tm.h.
(bit_SSSE3): New.
(host_detect_local_cpu): Check -mtune= vs. -march=. Rewrite
processor detection.
* config/i386/i386.h
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-05 14:30 ---
Shorter test:
real :: a(1,1), b(3)
integer :: i
b = 45.0
i = 2
a(1,1:i) = b(i)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-05 15:07 ---
Patch and testcase for the PR
This regtests OK on Cygwin_NT/PIV. I will submit it tonight.
It also regression tests ok on x86_64-unknown-linux-gnu; the patch itself also
looks ok.
--
--- Comment #1 from hjl at lucon dot org 2006-12-05 15:07 ---
Gcc 4.2 has the same problem. I am looking into it.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from hjl at lucon dot org 2006-12-05 15:49 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00297.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2006-12-05 15:51 ---
4.3 is fixed by
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00296.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #7 from tobi at gcc dot gnu dot org 2006-12-05 15:57 ---
Thanks Paul and Erik!
The patch regtests fine on i686-darwin together with my patch to enable
bounds-checking in the testsuite (and the workaround for PR29516, without which
gfortran is essentially unusable on
--- Comment #4 from hjl at lucon dot org 2006-12-05 16:06 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from hjl at gcc dot gnu dot org 2006-12-05 16:06 ---
Subject: Bug 30074
Author: hjl
Date: Tue Dec 5 16:06:39 2006
New Revision: 119545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119545
Log:
2006-12-05 H.J. Lu [EMAIL PROTECTED]
PR driver/30074
--- Comment #32 from pthaugen at us dot ibm dot com 2006-12-05 16:12
---
Another example, pared down from ammp benchmark in cpu2000.
void f2(int *, int *);
void mm_fv_update_nonbon(void)
{
int j, nx;
int naybor[27];
f2(naybor, nx);
for(j=0; j 27; j++)
if( naybor[j]) break;
--- Comment #33 from pthaugen at us dot ibm dot com 2006-12-05 16:30
---
My prior comment is missing the closing bracket for the procedure, but example
is otherwise complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #8 from patchapp at dberlin dot org 2006-12-05 16:45 ---
Subject: Bug number PR30003
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00306.html
--
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-12-05 18:05
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-12-05 18:05
---
Fixed.
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-12-05 18:05
---
Subject: Bug 14329
Author: pinskia
Date: Tue Dec 5 18:04:44 2006
New Revision: 119548
URL:
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-12-05 18:26
---
Subject: Bug 14784
Author: rakdver
Date: Tue Dec 5 18:26:20 2006
New Revision: 119549
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119549
Log:
PR tree-optimization/14784
*
---
atropine:~/combine-bug% cat foo.c
int foo(void) {
return 0;
}
atropine:~/combine-bug% cat bar.c
extern int foo(void);
void *array[] = {
foo
};
atropine:~/combine-bug% gcc -shared -fPIC -combine -fwhole-program -o libfoo.so
foo.c bar.c
atropine:~/combine-bug% nm libfoo.so | egrep
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-05 18:46 ---
If you use -fvisibility=hidden instead of -fwhole-program the result is even
worse, both foo and array are emitted even though the resulting DSO does not
give any access to them.
Well that is not GCC's fault
Annotations don't work with interpreted code
--
Summary: Annotations don't work with interpreted code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo:
--- Comment #1 from aph at gcc dot gnu dot org 2006-12-05 18:54 ---
Created an attachment (id=12749)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12749action=view)
.
Expected output:
class pp: @A1(enumF=ACE, doubleF=99.0, stringF=A1, arrayF=[1, 2], intF=0,
classF=class
--- Comment #12 from patchapp at dberlin dot org 2006-12-05 19:01 ---
Subject: Bug number PR 30009
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00334.html
--
--- Comment #2 from aph at gcc dot gnu dot org 2006-12-05 19:08 ---
The cause of this bug is that libgcj sorts fields so that static fields come
first, followed by instance fields. Any annotation indexes that refer to a
field will be wrong after this.
--
--- Comment #26 from patchapp at dberlin dot org 2006-12-05 19:15 ---
Subject: Bug number PR29975
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00336.html
--
/home/apinski/src/fsf/gcc/gcc/gcc/testsuite/g++.dg/tree-ssa/pr28003.C: In
function 'void __static_initialization_and_destruction_0(int, int)':^M
/home/apinski/src/fsf/gcc/gcc/gcc/testsuite/g++.dg/tree-ssa/pr28003.C:31:
error: insn does not satisfy its constraints:^M
(insn 2532 672 2533 4 (set
--- Comment #9 from pault at gcc dot gnu dot org 2006-12-05 19:33 ---
Subject: Bug 29912
Author: pault
Date: Tue Dec 5 19:32:59 2006
New Revision: 119554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119554
Log:
2006-12-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from ajax at redhat dot com 2006-12-05 19:37 ---
Just to clarify, I neglected to use -O in the example above, but this behaviour
is still seen even with -O.
--
ajax at redhat dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2] Cross compiler on |[4.2/4.3 Regression] Cross
|i386/x86-64 hosts
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-05 19:45 ---
I don't know what you mean by saying it reports the wrong return type.
In 3.4.0 I get a call to printf:
callg
testl %eax, %eax
jns .L2
movl$.LC0, (%esp)
call
--- Comment #9 from pault at gcc dot gnu dot org 2006-12-05 19:45 ---
Subject: Bug 30003
Author: pault
Date: Tue Dec 5 19:45:25 2006
New Revision: 119556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119556
Log:
2006-12-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-05 19:50 ---
(In reply to comment #2)
Hm. When you mark it as [4.0/4.1 Regression], should FIXED mean fixed
for 4.0/4.1?
Because it is hard to fix for 4.0/4.1 as either loop.c is causing this missed
optimization or the IR
--- Comment #3 from aph at gcc dot gnu dot org 2006-12-05 20:12 ---
Created an attachment (id=12750)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12750action=view)
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30076
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-05 20:40 ---
Mark as fixed. As enhancement it does not need to go into 4.2/4.1.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2006-12-05 20:51 ---
I think this was fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00427.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from mmitchel at gcc dot gnu dot org 2006-12-05 21:13
---
Jason, are you actively working on this? (We are motivated to fix the problem,
so if you're not working on it, then maybe we can help.)
HJ's patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html
--- Comment #1 from pault at gcc dot gnu dot org 2006-12-05 21:15 ---
(In reply to comment #0)
Examples taken from the Fortran 2003 standard, Section C.11.2.
They are not recognized as invalid.
BAD8 is, as of this evening's tree - I had to put an 'END' after the module so
as not to
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-05 21:15 ---
Subject: Bug 29495
Author: tromey
Date: Tue Dec 5 21:15:34 2006
New Revision: 119557
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119557
Log:
gcc/java
PR java/29495:
* jcf-parse.c
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-12-05 21:33
---
Subject: Bug 29728
Author: mmitchel
Date: Tue Dec 5 21:33:20 2006
New Revision: 119558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119558
Log:
PR c++/29728
* decl.c
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-05 21:36
---
Fixed in 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
The attached file contains a procedure that shows weird problems mixing tasks
and recursion.
A correct program behavior would be showing the same number of As and Bs, but
instead, for values of IMax 4 we get different counts.
gcc version 3.4.6 for GNAT GPL 2006 (20060522) running on windows
--- Comment #29 from hjl at lucon dot org 2006-12-05 21:41 ---
I am not sure if my patch handles hidden data reference properly. Should I work
on that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #30 from mark at codesourcery dot com 2006-12-05 21:51 ---
Subject: Re: Can't use __attribute__ ((visibility (hidden)))
to hide a symbol
hjl at lucon dot org wrote:
--- Comment #29 from hjl at lucon dot org 2006-12-05 21:41 ---
I am not sure if my patch handles
--- Comment #31 from pluto at agmk dot net 2006-12-05 22:00 ---
(In reply to comment #27)
(In reply to comment #26)
Created an attachment (id=12714)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12714action=view) [edit]
main_skel.o
It looks OK. Please provide a complete
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-05 22:02 ---
Right now, I cannot see why BAD9 does not throw an error - the code in
interface.c looks OK.
Ahhh, yes I can. gfc recurses through the formal interfaces of dummy
procedures - it actually does it correctly too!
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-12-05 22:15
---
(In reply to comment #9)
I think this was fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00427.html
No it was not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from bauhaus at futureapps dot de 2006-12-05 22:40 ---
Same when using gcc version 4.3.0 20061130 (experimental)
The only invariant in the output is that As Bs.
--
bauhaus at futureapps dot de changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-05 22:51 ---
Sorry, cancel the previous comments - I had a screwed up tree. What I said was
not correct.
BADx remains undetected by gfc
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-05 23:15 ---
(In reply to comment #2)
The compiler is failing to follow the documented behavior.
Because I (or anyone else) have not got around to actually testing the testcase
:).
--
--- Comment #32 from hjl at lucon dot org 2006-12-05 23:33 ---
(In reply to comment #31)
(In reply to comment #27)
(In reply to comment #26)
Created an attachment (id=12714)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12714action=view) [edit]
main_skel.o
It
This ICE was seen with revision 119560M:
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc
-4.3.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11
/lib/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/include -isystem
/op
The attached code generates a segmentation fault when compiled and run with
-O3. The error disappears if I inline any of the functions, remove any of the
unused class members, change the argument to min to be const int instead of
const int, etc, comment out any of the lines which do nothing, etc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||build
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-05 23:47 ---
This works with 4.3.0 20061116.
This might be a dup of bug 27768.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30080
-version -fPIC
-o xxx.s
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.
Breakpoint 3 at 0xc1225928
Breakpoint 3 at 0x7af827cc
GNU C version 4.3.0 20061205 (experimental) (hppa2.0w-hp-hpux11.11)
compiled
--- Comment #2 from irving at cs dot stanford dot edu 2006-12-05 23:54
---
(In reply to comment #1)
This works with 4.3.0 20061116.
This might be a dup of bug 27768.
27768 works fine for me (same options, or -O2).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30080
--- Comment #33 from hjl at lucon dot org 2006-12-05 23:58 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00361.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
1 - 100 of 114 matches
Mail list logo
