--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-19 08:38
---
On sparc-solaris I get runtime failures:
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined first referenced^M
symbol
--
Summary: operator in middle of expression is parsed as template
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from igodard at pacbell dot net 2005-11-19 10:11 ---
Created an attachment (id=10290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10290action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
--- Comment #2 from igodard at pacbell dot net 2005-11-19 10:12 ---
Created an attachment (id=10291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10291action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-19 10:12 ---
Bootstrapped and regtested on s390-linux-gnu for all default languages. We
already branched, so I leave it to you comitting the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-11-19 10:22
---
I don't know. There seems to be a latent problem in loop.c (no wonders). We
are currently trying to get rid of loop.c for 4.1 (by effectively disabling
it), so we may not care if this is not fixed. For 4.2 we
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:36
---
Created an attachment (id=10292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10292action=view)
proposed testsuite entry
Btw, did you remember to use -fno-inline? I still seem to be able to reproduce
it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|SUSPENDED |NEW
Last reconfirmed|2005-11-18 18:01:19 |2005-11-19
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:38
---
Changing the summary to reflect reality and remove some of the obscure-ness.
Mark, what was the obscureness you are refering to?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-19 11:29 ---
Subject: Bug 23294
Author: rguenth
Date: Sat Nov 19 11:29:10 2005
New Revision: 107218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107218
Log:
2005-11-19 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-19 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
libjava/configure uses $SED without defining it. Add a check for it, or
eliminate it's use? All other configure files directly use sed.
Matthias
--
Summary: libjava/configure uses $SED without defining it
Product: gcc
Version: 4.1.0
Status:
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-19 14:42
---
Uli, this still ICEs with current mainline. Any real fix in sight? Any chance
of committing the workaround? P5, as not a primary target.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-19 14:51 ---
How about Old style type declaration at %L not supported?
The 16 in complex*16 really isn't a kind type parameter, so
we should avoid calling it a kind. If you decide to go with
the above message, consider the patch
--- Comment #1 from bero at arklinux dot org 2005-11-19 15:00 ---
Created an attachment (id=10293)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10293action=view)
Simplified test case (this will become a jar)
Compile the attached minimalistic test case into a jar file:
tar xzf
--- Comment #2 from bero at arklinux dot org 2005-11-19 15:02 ---
Created an attachment (id=10294)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10294action=view)
Testcase, part 2
Step 2: Compile something that uses it
CLASSPATH=test.jar gcj -C test1.java
--
--- Comment #3 from bero at arklinux dot org 2005-11-19 15:03 ---
Step 3: Try running it.
CLASSPATH=test.jar gij test1
Prints Microsoft is crap with gcj 4.0.x, produces a segmentation fault with
today's SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
--- Comment #4 from bero at arklinux dot org 2005-11-19 15:16 ---
Also try:
gcj -O2 -fPIC -fjni -shared -o libtestcase.so test.jar
gcj -o testcase test1.java --main=test1 -L. -ltestcase
LD_LIBRARY_PATH=. ./testcase
Works as expected in 4.0.x, current SVN acts up: Generating
--- Comment #6 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18
---
Subject: Bug 24849
Author: dnovillo
Date: Sat Nov 19 15:18:08 2005
New Revision: 107220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107220
Log:
PR 24849
* omp-low.c
--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18
---
Workaround applied.
The actual solution separates lowering from optimization, once all the OMP
directives are lowered to a language-independent form, we can apply the
combined parallel+loop optimization without
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||kargl at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 16:22
---
(In reply to comment #13)
Changing the summary to reflect reality and remove some of the obscure-ness.
Mark, what was the obscureness you are refering to?
well both using BOOT_CFLAGS and profiledbootstrap
Given a program like this:
int foo(int a, int b, int c)
{
return a+b+c;
}
int bar(int a, int b, int c)
{
return foo(a, b, c);
}
int main(int argc, char **argv)
{
return bar(1,2,3);
}
for foo and bar, gcc generates code that stores the arguments a, b, and c on
the stack by using the
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-19 17:24 ---
Subject: Bug 23717
Author: rguenth
Date: Sat Nov 19 17:24:33 2005
New Revision: 107223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107223
Log:
2005-11-19 Richard Guenther [EMAIL PROTECTED]
Roger
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-19 17:25 ---
Subject: Bug 23717
Author: rguenth
Date: Sat Nov 19 17:25:41 2005
New Revision: 107224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107224
Log:
2005-11-19 Richard Guenther [EMAIL PROTECTED]
Roger
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-19 17:26 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from mark at codesourcery dot com 2005-11-19 17:34 ---
Subject: Re: [4.1 Regression] profilebootstrap failure
rguenth at gcc dot gnu dot org wrote:
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:38
---
Changing the summary to reflect
This topic was discussed in the following thread, but nothing seems to have
happened. I couldn't find a bug report.
http://gcc.gnu.org/ml/gcc/2003-09/msg01031.html
The test case below demonstrates some problems with arrays of aligned types.
Packing the aligned type in a structure fixes the
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-19 18:31 ---
I think this is a dup of your older bug, PR 20308.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-19 18:34 ---
Yep it is a dup:
templatetypename T, templatetypenameclass al
void slistT, al::merge(slistT, al l) {
node_type* cursor = before_begin().iter;
while(cursor-next != nil !l.empty()) {
if (l.head-val
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-19 18:34 ---
*** Bug 24939 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-19 18:39 ---
SED comes from shlibpath.m4 which has:
# shlibpath.m4 - Define LTDL_SHLIBPATH_VAR. -*-Autoconf-*-
So isn't this really just an import from libtool?
I think you should be complaining there instead of here.
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 18:42
---
I must had missed -fno-inline. This is still reproducable for me on the
mainline and the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from milan at cmm dot ki dot si 2005-11-19 19:09 ---
I didn 't know how to compile gcc-4.1... so I couldn't reply before. I realised
I have to install both mpfr and gmp libraries for gcc to compile. It complains
only about gmp :-(
Yes, this patch works OK. I had to
I am trying to open the same file twice. This works in g77, but fails in
gfortran-4.1-20051112 snapshot
This is the program:
integer iun,irecl
iun=1
irecl=5
open(unit=iun,file='uu',status='unknown',access='direct',
$ form='unformatted',recl=8*irecl)
C
--- Comment #6 from schnetter at aei dot mpg dot de 2005-11-19 19:38
---
Created an attachment (id=10295)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10295action=view)
Patch with better error messach
I've change the error message so that it doesn't use the expression kind
where
--- Comment #16 from rrr6399 at futuretek dot com 2005-11-19 20:24 ---
Created an attachment (id=10296)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10296action=view)
Patch to change delimitters to 4 bytes for unformatted records
This is nearly the same patch that I posted before
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-19 20:43
---
I have the patch for this working and will be submitting to the list for
approval soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
--- Comment #2 from kazu at gcc dot gnu dot org 2005-11-19 20:48 ---
I'm pretty sure this is a duplicate of PR 24912, which has got more analysis.
*** This bug has been marked as a duplicate of 24912 ***
--
kazu at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-19 20:48 ---
*** Bug 24850 has been marked as a duplicate of this bug. ***
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
CC||kazu at gcc dot gnu dot org
Summary|m68k build failure: ICE:
--- Comment #4 from kazu at gcc dot gnu dot org 2005-11-19 21:05 ---
Is this still reproducible?
A quick check with m68k-none-elf did not reproduce the ICE.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-19 21:13 ---
Jonathan,
The testcase seems to work with GCC 4.1.
As far as getting the testcase into the testsuite, you need to post a patch
first.
The best thing to do at this point is to reduce the testcase so that it will be
--- Comment #2 from kazu at gcc dot gnu dot org 2005-11-19 21:19 ---
Confirmed with m68k-none-elf.
Probably not specific to RTEMS.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-19 21:26 ---
Slightly reduced to:
extern void bar (unsigned char, unsigned char, unsigned char);
void
foo (unsigned char *key, unsigned int round)
{
unsigned char a = 0, b = 0, c = 0;
while (round-- 0)
{
a ^=
--- Comment #6 from jb at gcc dot gnu dot org 2005-11-19 21:36 ---
Subject: Bug 24862
Author: jb
Date: Sat Nov 19 21:36:06 2005
New Revision: 107228
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107228
Log:
fortran ChangeLog:
2005-11-19 Janne Blomqvist [EMAIL PROTECTED]
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-19 21:52 ---
FWIW, the mainline gcc with -O2 -fomit-frame-pointer produces
f:
move.l 4(%sp),%a0
move.l (%a0),%a1
move.l 4(%a0),%a0
clr.b (%a0,%a1.l)
rts
--
kazu at gcc dot gnu dot org
--- Comment #8 from hp at gcc dot gnu dot org 2005-11-19 21:54 ---
Subject: Bug 24912
Author: hp
Date: Sat Nov 19 21:54:26 2005
New Revision: 107230
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107230
Log:
PR middle-end/24912
* gcc.dg/torture/pr24912-1.c: New
--- Comment #14 from hp at gcc dot gnu dot org 2005-11-19 21:56 ---
Subject: Bug 24750
Author: hp
Date: Sat Nov 19 21:56:17 2005
New Revision: 107231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107231
Log:
PR middle-end/24912
PR middle-end/24750
*
--- Comment #9 from hp at gcc dot gnu dot org 2005-11-19 21:56 ---
Subject: Bug 24912
Author: hp
Date: Sat Nov 19 21:56:17 2005
New Revision: 107231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107231
Log:
PR middle-end/24912
PR middle-end/24750
*
--- Comment #10 from hp at gcc dot gnu dot org 2005-11-19 21:58 ---
Subject: Bug 24912
Author: hp
Date: Sat Nov 19 21:58:23 2005
New Revision: 107232
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107232
Log:
PR middle-end/24912
* gcc.dg/torture/pr24912-1.c: New
--- Comment #11 from hp at gcc dot gnu dot org 2005-11-19 21:59 ---
Subject: Bug 24912
Author: hp
Date: Sat Nov 19 21:59:48 2005
New Revision: 107233
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107233
Log:
PR middle-end/24912
PR middle-end/24750
*
--- Comment #15 from hp at gcc dot gnu dot org 2005-11-19 21:59 ---
Subject: Bug 24750
Author: hp
Date: Sat Nov 19 21:59:48 2005
New Revision: 107233
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107233
Log:
PR middle-end/24912
PR middle-end/24750
*
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-19 22:03 ---
Subject: Bug 24862
Author: jb
Date: Sat Nov 19 22:03:41 2005
New Revision: 107234
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107234
Log:
fortran ChangeLog:
2005-11-20 Janne Blomqvist [EMAIL PROTECTED]
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #26 from pcarlini at suse dot de 2005-11-19 22:12 ---
Created an attachment (id=10297)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10297action=view)
Reduced from thread/pthread3
Richard, I'm attaching a really minimal testcase, which fails very quickly
for me with
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-19 22:32
---
Confirmed (though I don't know why it should work and how it should behave).
Intel accepts this too.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
make[8]: Leaving directory `/home/dave/gcc-4.1/objdir/gcc/ada/rts'
rm -f rts/libgnat.a rts/libgnarl.a
rc rts/libgnat.a \
rts/a-caldel.o rts/a-calend.o rts/a-cdlili.o rts/a-cgaaso.o rts/a-cgarso.o
rt
...
It seems AR_FOR_TARGET didn't expand to ar.
2005-11-14 Arnaud Charlet [EMAIL PROTECTED]
--- Comment #27 from rguenth at gcc dot gnu dot org 2005-11-19 22:38
---
The only thing in the pthread3_reduced.cc testcase that could make it going
wrong is wrong alignment of aw. And I remember seeing a lot of unaligned traps
in dmesg during libstdc++ testing on ia64.
--
--- Comment #28 from pcarlini at suse dot de 2005-11-19 22:45 ---
Thanks Richard G. In fact, from time to time I saw warnings on the shell,
which really puzzled me, because I was sure that no alignment issues were
present anymore in the higher lever library code proper.
I'll try to add
--- Comment #29 from pcarlini at suse dot de 2005-11-19 23:02 ---
(In reply to comment #28)
I'll try to add an alignment attribute to the _Atomic_word typedef, as cris
is already doing for instance, and see whether something changes for the
better.
Nope. Maybe the alignment is for
--- Comment #30 from pcarlini at suse dot de 2005-11-19 23:06 ---
Created an attachment (id=10298)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10298action=view)
Further reduced, pure C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #31 from schwab at suse dot de 2005-11-20 00:22 ---
Testing this patch:
Index: ia64.c
===
--- ia64.c (revision 107220)
+++ ia64.c (working copy)
@@ -2113,7 +2113,7 @@
emit_insn (GEN_FCN (icode)
--- Comment #4 from kazu at gcc dot gnu dot org 2005-11-20 00:22 ---
Created an attachment (id=10299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10299action=view)
Patch
With this patch, I get:
f:
move.l 4(%sp),%a0
move.l (%a0),%a1
add.l 4(%a0),%a1
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 00:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-20 00:43 ---
Yes this is a dup of bug 24569 which was fixed for 4.0.3.
*** This bug has been marked as a duplicate of 24569 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-20 00:43 ---
*** Bug 24874 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When compiling with -Os and -Winline, many warnings like this occur:
file.cc:25: warning: inlining failed in call to 'function': --param
inline-unit-growth limit reached
because the optimizer's inlining code gives up too early. The parameters most
commonly exceeded are max-inline-insns-single,
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-20 01:16 ---
See 9.3.4 from the standard.
If a unit is connected to a file that exists, execution of an OPEN statement
for that unit is permitted. If the FILE= specifier is not included in such
an OPEN statement, the file to be
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 01:31 ---
For 4.1, with -Os, -finline-functions is enabled, and the inlining params have
been changed so that it has been tuned for -Os and csibe
http://www.csibe.org/.
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-20 02:00
---
Patch submitted for review and approval. Christoph, thankyou for submitting
this PR and the example case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
I believe gcc is in error for calling the int* overload in the program below.
Sorry if this is a duplicate -- I went through the many lookup bugs in Bugzilla
but none of them looked quite like this one.
$ cat t.cpp g++ -pedantic -W t.cpp ./a.out
#include assert.h
int foo (void*) { return 0; }
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 03:04 ---
This was fixed by the same patch which fixed PR 2922. The issue was that GCC
was not keeping track of the overloaded set.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-20 03:06 ---
I bootstraped and tested this on x86_64-linux-gnu with no regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
--- Comment #1 from tausq at debian dot org 2005-11-20 03:38 ---
I forgot to mention that the above was compiled with gcc -g -o dwarfbug
dwarfbug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
With 4.1, gcc.c-torture/compile/2403-2.c fails
Here is a slightly reduced test case.
void
foo (long long tmp)
{
tmp = tmp 32;
}
2403-2.c: In function 'foo':
2403-2.c:5: error: unrecognizable insn:
(insn 8 6 9 1 (set (mem/c/i:DI (reg/f:SI 25 virtual-incoming-args) [0 tmp+0 S8
--- Comment #6 from rth at gcc dot gnu dot org 2005-11-20 05:37 ---
Subject: Bug 24665
Author: rth
Date: Sun Nov 20 05:37:08 2005
New Revision: 107244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107244
Log:
PR tree-opt/24665
* tree-gimple.c (is_gimple_id):
--- Comment #5 from corsepiu at gcc dot gnu dot org 2005-11-20 05:38
---
(In reply to comment #4)
Is this still reproducible?
A quick check with m68k-none-elf did not reproduce the ICE.
Confirmed, I can't reproduce it with my latest rtems-toolchain:
m68k-rtems4.7-gcc (GCC) 4.0.1
--- Comment #32 from rth at gcc dot gnu dot org 2005-11-20 05:43 ---
Oh good grief. I can't see the forest for the trees. Andreas, I expect
that patch will work. If it tests ok, please commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #32 from lucier at math dot purdue dot edu 2005-11-20 07:13
---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
On Nov 19, 2005, at 1:50 AM, lucier at math dot purdue dot edu wrote:
Can you explain what Apple's libtool has to do with it? Is it used
by
81 matches
Mail list logo
