--- 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
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-06 00:01 ---
(gdb) p debug_tree (arg)
gimple_modify_stmt 7ad661f8 side-effects
arg 0 var_decl 7ad62528 ap
type pointer_type 7ae77960 va_list type void_type 7adf0900 void
sizes-gimplified unsigned SI
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-06 00:05 ---
2006-12-05 Aldy Hernandez [EMAIL PROTECTED]
Merge from gimple-tuples-branch.
2006-12-04 Aldy Hernandez [EMAIL PROTECTED]
* config/s390/s390.c (s390_va_start): Replace MODIFY_EXPR with
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-06 00:07 ---
t = build2 (GIMPLE_MODIFY_STMT, valist_type, valist, t);
ofs = (8 - size) % 4;
if (ofs != 0)
{
u = fold_convert (valist_type, size_int (ofs));
t = build2 (PLUS_EXPR,
--- Comment #2 from kkojima at gcc dot gnu dot org 2006-12-06 00:40 ---
I've looked at what is going on. The variable block is
placed at sfp - 4 where sfp is the software frame pointer.
Then the expression (unsigned long) buf - 0x8000 is
sfp - 0x8000 - 4. The cse pass folds
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-06 01:46
---
Subject: Bug 29728
Author: mmitchel
Date: Wed Dec 6 01:46:26 2006
New Revision: 119574
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119574
Log:
PR c++/29728
* decl.c
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-12-06 02:55 ---
Subject: Re: Missed optimizations with -fwhole-program -combine
I would not expect this to be fixed anytime soon. I have yet to find
any real people who use either combine or -fwhole-program. They use
*way* too
I would not expect this to be fixed anytime soon. I have yet to find
any real people who use either combine or -fwhole-program. They use
*way* too much memory on real programs. As a result, no real people
involved in optimization work on optimizers for them.
On 5 Dec 2006 19:38:51 -,
--- Comment #4 from bhaskar dot priya at wipro dot com 2006-12-06 03:08
---
The Bug was a mistake in the transformation engin we were using...
sorry for the bug report (it turned out to be False Positive)
sorry
--
bhaskar dot priya at wipro dot com changed:
What
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #4 from acahalan at gmail dot com 2006-12-06 04:07 ---
(In reply to comment #3)
(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
:).
I still don't see
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-06 05:12
---
Subject: Bug 29729
Author: mmitchel
Date: Wed Dec 6 05:12:46 2006
New Revision: 119575
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119575
Log:
PR c++/29729
* decl2.c
--- Comment #34 from mark at codesourcery dot com 2006-12-06 06:44 ---
Subject: Re: Can't use __attribute__ ((visibility (hidden)))
to hide a symbol
hjl at lucon dot org wrote:
--- Comment #33 from hjl at lucon dot org 2006-12-05 23:58 ---
The updated patch is posted at
--- Comment #35 from hjl at lucon dot org 2006-12-06 06:55 ---
(In reply to comment #34)
Subject: Re: Can't use __attribute__ ((visibility (hidden)))
to hide a symbol
hjl at lucon dot org wrote:
--- Comment #33 from hjl at lucon dot org 2006-12-05 23:58 ---
The
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-06 07:24 ---
That the ambiguity in BAD8 is not detected is a regression; with 4.1 and
yesterday's 4.2 I get:
Error: Ambiguous interfaces 's8b' and 's8a' in generic interface 'bad8' at (1)
I didn't check whether this is due to
79 matches
Mail list logo