--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-01-27 08:59
---
(In reply to comment #8)
So I still say we should just require makeinfo when building from
SVN/snapshot.
There is no reason not really.
Yes there are reasons: for example, makeinfo does not easily build on
--- Comment #2 from patchapp at dberlin dot org 2007-01-27 09:15 ---
Subject: Bug number PR24924
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/2007-01/msg02234.html
--
--- Comment #10 from dannysmith at users dot sourceforge dot net
2007-01-27 10:06 ---
(In reply to comment #9)
(In reply to comment #8)
So I still say we should just require makeinfo when building from
SVN/snapshot.
There is no reason not really.
Yes there are reasons: for
--- Comment #1 from mtrudel at gmx dot ch 2007-01-27 10:12 ---
I can confirm that. However, I don't know if it's a bug or just luck that it
worked before. I think the correct command would be:
gcj -C -Ix x/a.java (no space between -I and x)
This way it works and I think (I'm absolutely
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-01-27 13:24 ---
Here's a patch for the m4 part:
Index: m4/iparm.m4
===
--- m4/iparm.m4 (revision 121230)
+++ m4/iparm.m4 (working copy)
@@ -28,6 +28,6 @@
--- Comment #6 from patchapp at dberlin dot org 2007-01-27 13:40 ---
Subject: Bug number PR 15787
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/2007-01/msg02238.html
--
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-01-27 13:46
---
When introducing this, I was in good faith that automake is capable to handle
any issues that may arise. Since the *.info files are not kept in SVN, as
`missing` seems to assume, the fail safe backfires.
I will
During make of the version 4.3.0 20070112 of the GCC compiler I have the
following error:
/cygdrive/h/cross_compiler/compiler_gcc/./prev-gcc/xgcc
-B/cygdrive/h/cross_compiler/compiler_gcc/./prev-gcc/
-B/usr/local/gcc-4.3-20070112/i686-pc-cygwin/bin/ -c -g -O2 -gnatpg -gnata
-I- -I. -Iada
--- Comment #1 from mbo dot massimo at tiscali dot it 2007-01-27 14:33
---
Created an attachment (id=12969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12969action=view)
configure and make logs
configure and make logs produced during GCC generation
--
In this, the expression a0 is evaluated twice,
both in the *.original and the *.optimized dump:
function average(a, n)
real :: average
real :: a(n)
average = sum(a, a0)/count(a0)
end function average
$ cat average.f90.003t.original
average (a, n)
{
int4 ubound.0;
int4 size.1;
real4
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-27 15:45 ---
The funny thing is that if we fix this, bootstrap will break (with a warning
treated as an error) on tree-optimize.c (update_inlined_to_pointers) since it
seems that that function is only used by itself.
Is it dead
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-27 15:46 ---
Anyway, here is my current patch, perhaps someone can find some use for it:
Index: gcc/testsuite/gcc.dg/Wunused-function.c
===
---
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-01-27 15:57 ---
update_inlined_to_pointers is obviously no longer needed and can be safely
removed now. Thanks for noticing it ;)
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-27 16:04 ---
So then, should I prepare two separated patches or just one for everything ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
Happen with gcc43 snapshot 20070105 (experimental).
gcc configured with: ./..//gcc-4.3-20070105/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=43 --libdir=/usr/local/lib/gcc-4.3.0
--- Comment #1 from kcwu at csie dot org 2007-01-27 16:26 ---
Created an attachment (id=12970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12970action=view)
eats 1321MB memory and 8minutes to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
--- Comment #5 from patchapp at dberlin dot org 2007-01-27 16:35 ---
Subject: Bug number PR 30389
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/2007-01/msg02245.html
--
The code is invalid (13.14.89 says about NCOPIES
Its value should not be negative), but the
error message could definitely be improved :-)
$ cat rep.f90
program main
integer :: i
character(len=10) :: from
from = -1
read(unit=from, fmt=(I10)) i
print *,repeat (a, i)
end program main
$
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-27 16:49 ---
How would you test whether this is fixed?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-27 16:51 ---
All time is suck up in PRE:
tree PRE : 36.36 (93%) usr 0.40 (95%) sys 36.85 (93%) wall
88918 kB (96%) ggc
TOTAL : 39.03 0.4239.74
92276 kB
We have seen several regressions and PRs with respect to this. It is possible
to workaround this by using:
/* { dg-bogus message.*message } */
/* { dg-warning message { target *-*-* } 1 } */
However, the test must be alone in one file. Otherwise, strange things may
happen.
This is obviously
the command:
gfortran -static -fopenmp -o xomp xomp.f
works OK, but I when executing xomp it segfaults:
export OMP_NUM_THREADS=2
./xomp
Segmentation fault
if compiling with:
gfortran -static -fopenmp -o xomp xomp.f
everything is OK. This happens with any OpenMP program. Here is a simple
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-27 17:07 ---
It's of course caused by the new partial-antic stuff, but still something is
out of a reasonable bound here (we're just iterating 2 times to solve partial
antic).
--
gcc reports two different error messages, the second of them doesn't
seem to be correct. If it is somehow correct (I don't think so),
it is still misleading:
$ gnatmake -gnatv p.adb
gcc -c -gnatv p.adb
GNAT 4.3.0 20070127 (experimental)
Copyright 1992-2006, Free Software Foundation, Inc
--- Comment #7 from kargl at gcc dot gnu dot org 2007-01-27 17:14 ---
Subject: Bug 30278
Author: kargl
Date: Sat Jan 27 17:14:06 2007
New Revision: 121234
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121234
Log:
2007-01-26 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #8 from kargl at gcc dot gnu dot org 2007-01-27 17:16 ---
Fixed in 4.1, 4.2, and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-27 17:24 ---
After fixing the code to some that even has a just to compile,
I've compiled this with gfortran from the 4.1 branch, 4.2 branch,
and trunk. Closing with 'works for me'.
--
kargl at gcc dot gnu dot org changed:
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 17:33 ---
Works for me with both the 4.2 branch and trunk gfortran.
troutmask:sgk[235] gfc4x -o z -fopenmp -static t.f
troutmask:sgk[236] ./z
n,p= 0 0.00
n,p= 0 0.00
troutmask:sgk[237]
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 17:42 ---
Found the message.
http://gcc.gnu.org/ml/gcc-bugs/2007-01/msg02248.html
*** This bug has been marked as a duplicate of 30471 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from kargl at gcc dot gnu dot org 2007-01-27 17:42 ---
*** Bug 30613 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
When building mysql server 5.0.33 from ports on FreeBSD 6.0-RELEASE, I get the
following c++ error:
[EMAIL PROTECTED] [/usr/ports/databases/mysql50-server]# make WITH_OPENSSL=yes
WITHOUT_INNODB=yes
=== Building for mysql-server-5.0.33
make all-recursive
Making all in include
make all-am
Making
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org
|dot org
--- Comment #13 from patchapp at dberlin dot org 2007-01-27 18:05 ---
Subject: Bug number PR c++/29106
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/2007-01/msg02248.html
--
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-27 18:23 ---
Subject: Bug 30407
Author: pault
Date: Sat Jan 27 18:23:14 2007
New Revision: 121235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121235
Log:
2007-01-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-27 19:05 ---
How much memory do you have? This internal error is caused by the kernel
killing the process because it ran over the memory limits.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
in semaphore_wait_signal_trap ()
#1 0x90001d90 in pthread_mutex_lock ()
#2 0x0020093c in get_external_unit (n=6, do_create=3331) at
../../../gcc-4.3-20070127/libgfortran/../gcc/gthr-posix.h:604
#3 0x001ff6e0 in data_transfer_init (dtp=0x6004d8, read_flag=3331) at
../../../gcc-4.3-20070127/libgfortran/io/transfer.c:1698
--- Comment #8 from stevenb dot gcc at gmail dot com 2007-01-27 19:58
---
Subject: Re: -Wunused doesn't warn about static function only called by
itself.
Just one for everything should suffice.
Or, if you prefer, you can remove that one function with a separate
patch first, which, I
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-01-27 19:58
---
Subject: Bug 28284
Author: reichelt
Date: Sat Jan 27 19:58:38 2007
New Revision: 121238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121238
Log:
Backport:
2006-11-13 Mark Mitchell
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-01-27 19:58
---
Subject: Bug 29106
Author: reichelt
Date: Sat Jan 27 19:58:38 2007
New Revision: 121238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121238
Log:
Backport:
2006-11-13 Mark Mitchell
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-27 20:03 ---
This patch looks reasonable to me, though I cannot approve it.
The formatting is slightly wrong, there should be a space
between the if and the (.
Also a ChangeLog entry is required.
--
tromey at gcc dot gnu dot
--- Comment #2 from drow at gcc dot gnu dot org 2007-01-27 20:20 ---
Testing a patch.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27416
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 21:31 ---
I believe recursive IO is undefined (except maybe in some very limited
situations), but I can't locate anything in the F95 Standard that says
this. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 21:38 ---
(In reply to comment #1)
I believe recursive IO is undefined (except maybe in some very limited
situations), but I can't locate anything in the F95 Standard that says
this. :(
Okay I found the relevant passage.
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-27 21:41 ---
This works with 4.3.0 20070127 on powerpc-darwin with -O3 and -O3 -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
--- Comment #3 from dominiq at lps dot ens dot fr 2007-01-27 21:43 ---
I believe recursive IO is undefined
Probably, but the same code works with
Target: x86_64-unknown-linux-gnu
gcc version 4.3.0 20061231 (experimental)
on a linux AMD64.
--
--- Comment #11 from andreast at gcc dot gnu dot org 2007-01-27 21:46
---
Subject: Bug 30513
Author: andreast
Date: Sat Jan 27 21:46:15 2007
New Revision: 121239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121239
Log:
2007-01-27 Andreas Tobler [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-27 21:47 ---
This might be a bug in Mac OS X's libraries.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-27 21:51
---
I recall some time ago working on the patch that enabled this feature.
I agree this is probably platform specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-27 22:01 ---
Subject: Re: recursive I/O hangs under OSX 10.3
I agree this is probably platform specific.
Can someone do the test on a Macintel? TIA
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #3 from dcb314 at hotmail dot com 2007-01-27 22:12 ---
(In reply to comment #2)
This should be fixed with
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01728.html I think.
I suspect not.
The snapshot 20070126 still seems to have the problem.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-27 22:30 ---
(In reply to comment #7)
This works with 4.3.0 20070127 on powerpc-darwin with -O3 and -O3 -m64.
Ok, I had to change a paramater internal to GCC to get it to reproduce on
ppc-darwin but I am able to with today's
--- Comment #6 from steven at gcc dot gnu dot org 2007-01-27 22:30 ---
Approval of the patch at
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01429.html was posted today:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02253.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
--- Comment #3 from kaloian at doganov dot org 2007-01-27 23:14 ---
Created an attachment (id=12971)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12971action=view)
Trivial fix -- `inlenght' is the last valid index of the buffer, so it should
be used directly, without adding it to
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-27 23:31 ---
The problem is we are calling fold_marked_statements after renumbering the
basic blocks and such which causes us to get the wrong starting point.
patch which I am tesing:
Index: ../../gcc/tree-inline.c
--- Comment #7 from kargl at gcc dot gnu dot org 2007-01-27 23:34 ---
(In reply to comment #3)
I believe recursive IO is undefined
Probably, but the same code works with
Target: x86_64-unknown-linux-gnu
gcc version 4.3.0 20061231 (experimental)
Undefined means undefined.
This is Debian bug #408703; see the attached files that reproduce
the problem. The command line is
gnatmake integer_indexed_io-debug.ads
After successfully compiling a couple of files, gnat1 then goes into
an infinite loop while parsing integer_indexed_io-debug.ads. The
backtrace I got when
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-01-27 23:54
---
Created an attachment (id=12972)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12972action=view)
Source files to reproduce the problem
In order to reproduce the bug, extract the sources in it and say:
--- Comment #8 from kuba at et dot pl 2007-01-28 00:02 ---
Subject: Re: incorrect warning when using
firstprivate and lastprivate clauses
I realised that maybe is just better to set
TREE_NO_WARNING (fd-v) = 1;
instead of set it (fd-v) to 0.
We are sure that fd-v won't be read
from cp/cp-tree.h:
/* Used to store the operation code when in a template context. */
#define OMP_ATOMIC_CODE(NODE) \
(OMP_ATOMIC_CHECK (NODE)-exp.complexity)
This is blocking the removal of TREE_COMPLEXITY, which is a significant source
of waste of memory in gcc.
--
Summary:
-largefile
Thread model: posix
gcc version 4.2.0 20070127 (prerelease)
Please let me know if additional information is required.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-28 00:38 ---
Created an attachment (id=12973)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12973action=view)
patch which needs testing and a little cleanup including documentation/comment
fixes
I quickly tested this on:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 00:49 ---
I have a fix for the line number issue I found after creating the above patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30619
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-28 03:00 ---
(In reply to comment #3)
Clearing browser cache helped. Maybe bugzilla did not mark a page as changed
that had in fact changed for some reason. I'm ready to provide additional
information if I can. Just ask.
--- Comment #2 from roger at eyesopen dot com 2007-01-28 02:58 ---
Hi Andrew, could you recheck whether you can reproduce this problem on
mainline?
Updating the MODIFY_EXPR patch in PR 22368 to check GIMPLE_MODIFY_STMT, I'm
unable to reproduce this failure on x86_64-unknown-linux-gnu,
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-28 02:41 ---
(In reply to comment #7)
I seem to recall that when Giovanni worked on these digraph thingies,
it was pointed out that our CPP is able to mark a pp-token whether it
is a digraph or not.
Actually, it is marked as
--- Comment #16 from drow at gcc dot gnu dot org 2007-01-28 03:48 ---
Actually, I was wrong - we shouldn't try to make this case work. If you use
$prefix/$target_alias as a sysroot, then /bin/as in your sysroot needs to be a
host-x-target assembler!
Closing instead.
--
drow at gcc
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-28 04:11 ---
Subject: Re: When using 'or' keyword, the error message speaks of a '||' token
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Unless someone decides to fix the whole C++ parser error handling,
| this and PR
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-28 07:58
---
The problem is we are calling fold_marked_statements after renumbering the
basic blocks and such which causes us to get the wrong starting point.
We have to call verify_cgraph before calling
69 matches
Mail list logo
