--- Comment #2 from mirko dot bruzzone at primeur dot com 2006-05-26 07:33
---
(In reply to comment #1)
> Good morning,
> I tried to compile the gcc version 4.0.3 on this platform:
>
> UNIX_SV ulisse 4.0 3.0 3425/3482/3485 Pentium III(TM)-ISA/PCI
>
> On the system there is an old
--- Comment #6 from bonzini at gnu dot org 2006-05-26 07:46 ---
There are indeed differences in the generated code.
aj_f_times2 is equal without and with the patch.
aj_d_times2 has this (left = old, right = patched):
movsd %xmm0, -40(%rbp) | movsd %xmm0, -32(%r
I know that the ABI calling convention require that function results are
returned as integers, even if the function result is known as
(short)byte-value.
But if a function with its return is inlined, i can't see any reason to
(over)fullfill this convention. At least with optimizing compilation th
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-26 08:31
---
(In reply to comment #18)
> This patch is beyond my current understanding, so someone else needs to look
> at
> it.
I think our best chance here is to find the exact patch that broke it. You said
it's between r
--- Comment #1 from familie dot glaser at web dot de 2006-05-26 08:34
---
Created an attachment (id=11513)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11513&action=view)
preprocessed c++-example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #2 from familie dot glaser at web dot de 2006-05-26 08:37
---
Created an attachment (id=11514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11514&action=view)
assembler-listing with markup-comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 ---
Subject: Bug 27743
Author: rguenth
Date: Fri May 26 09:53:01 2006
New Revision: 114128
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114128
Log:
2006-05-26 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from aph at gcc dot gnu dot org 2006-05-26 10:20 ---
I have found the real cause of these weird non-nested variable ranges.
It's because ecj reorganizes for loops in this way:
for (a; b; c)
{
foo;
}
becomes
goto barf;
do
{
foo;
c;
barf:
a;
if (!b)
goto x;
--- Comment #6 from aph at gcc dot gnu dot org 2006-05-26 10:23 ---
Err, I mean:
a;
goto barf;
do
{
foo;
c;
barf:
if (!b)
goto x;
} forever;
x:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
I get testsuite failures in mpfr compiling for s390 with
/usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed mul.i -quiet -dumpbase
mul.c -march=z900 -mtune=z9-109 -m31 -mesa -auxbase mul -O2 -Wall -version
-fmessage-length=0 -fPIC -o mul.s
s390z27:/usr/src/packages/BUILD/mpfr-2.2.0/tests# LD_L
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-26 10:32 ---
Created an attachment (id=11515)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11515&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-26 11:00 ---
Works for me without all the volatile crap.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from berndtrog at yahoo dot com 2006-05-26 11:15 ---
This bug is target independent.
I see the same behaviour for --target=mingw32.
Workaround (for avr only):
Index: mlib-utl.adb
===
--- mlib-utl.adb
--- Comment #2 from lcampbel at akamai dot com 2006-05-26 11:37 ---
Any chance this will get fixed any time soon? I think all you have to do is to
change a NULL to &_objc_thread_attribs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
--- Comment #5 from falk at gcc dot gnu dot org 2006-05-26 12:29 ---
Subject: Bug 27571
Author: falk
Date: Fri May 26 12:28:40 2006
New Revision: 114130
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114130
Log:
PR target/27571
* config/alpha/alpha.c (alpha_does_
--- Comment #6 from falk at debian dot org 2006-05-26 12:30 ---
Fixed.
--
falk at debian dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ ("lr %N0,%1\n\tmr %0,%2" : "=&r" (__x.__ll)
With the attached source, gcc version 4.2.0 20060524 (experimental) gets:
/usr/snp/bin/gfortran -S -O2 -ffast-math imhdiff4_pp.f
imhdiff4_pp.f: In function 'imhdiff4':
imhdiff4_pp.f:1: internal compiler error: in find_lattice_value, at
tree-complex.c:133
Note the use of -ffast-math - without it,
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:02 ---
Created an attachment (id=11516)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11516&action=view)
Source file showing the wrong behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:06 ---
Changed summary to indicate this bug is a 4.2 regression.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--
--- Comment #7 from aph at gcc dot gnu dot org 2006-05-26 13:52 ---
Subject: Bug 27756
Author: aph
Date: Fri May 26 13:52:18 2006
New Revision: 114131
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114131
Log:
2006-05-25 Andrew Haley <[EMAIL PROTECTED]>
PR java/27756
--- Comment #8 from aph at gcc dot gnu dot org 2006-05-26 13:54 ---
What am I supposed to write here, anyway? It's fixed because I fixed it.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from dje at gcc dot gnu dot org 2006-05-26 14:07 ---
The patch you reference enables section anchors by default. Neither AIX nor
PPC Linux show new Gfortran testsuite failures from the use of section anchors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
--- Comment #8 from jakub at gcc dot gnu dot org 2006-05-26 14:17 ---
Subject: Bug 25758
Author: jakub
Date: Fri May 26 14:17:47 2006
New Revision: 114132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114132
Log:
PR target/27758
Backported from mainline
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-26 14:17 ---
Subject: Bug 27758
Author: jakub
Date: Fri May 26 14:17:47 2006
New Revision: 114132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114132
Log:
PR target/27758
Backported from mainline
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-26 14:19 ---
Subject: Bug 27758
Author: jakub
Date: Fri May 26 14:19:16 2006
New Revision: 114133
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114133
Log:
PR target/27758
* gcc.dg/pr27758.c: New test.
Ad
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:56 ---
This didn't fail with 4.0.2pre, so it must be a regression on a release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
--- Comment #21 from konqueror at gmx dot de 2006-05-26 14:58 ---
Can this please get backportet to the 4.1 branch? This bug is still holding
back some Java stuff on Debian/ia64 from being working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:59 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:00 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:04 ---
(In reply to comment #1)
> I think GCC 4.2.0 is correct in saying the function call is ambiguous, bar is
> still a template class.
Most definitely, foo::bar is not a template class, and the only
thing the call to f() ca
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:04 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed..
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:08 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:14 ---
Confirmed. Though it is worth mentioning that icc has the same "problem".
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:16 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:18 ---
This works fine with 4.0.2, and 4.1-pre and 4.2-pre snapshots I have here.
Could you check that it works for you as well with a recent snapshot?
Thanks
W.
--
bangerth at dealii dot org changed:
What
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:21 ---
> template
> void f(A, vector A, int);
You meant __vector here.
Certainly, the expectation is that the vector attribute will apply to the
type only after instantiation. Whether that is feasible is a different
matter.
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-05-26 14:58 ---
Just for completeness' sake: confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:26 ---
gcc parses this as
template
typename A::I foo (T) { return 0; }
i.e. as meaning that the argument is not an integer, but a function that
returns an integer.
A simpler testcase is this (icc accepts it, though I'm not
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:28 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:29 ---
Confirmed, but low priority. One should just follow the first error message.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:37 ---
Confirmed. We should not be calling the conversion operator.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:38 ---
As mentioned before, this is legal code.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:15 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 16:31 ---
D.1024_166 = COMPLEX_EXPR ;
D.1025_167 = 1.0e+0 - D.1024_166;
That is wrong, that 1.0 should be complex_cst < 1.0e+0, 0.0>
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from tneumann at pi3 dot informatik dot uni-mannheim dot de
2006-05-26 16:35 ---
This still happens with gcc-4.0-20060518, see the error message below. The
gcc-4.[12] branches presumably work, I only tried 4.1.
./gcc4/bin/g++ -c foo.cpp
foo.cpp: In member function 'unsig
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-26 16:38 ---
More reduced testcase:
subroutine imhdiff4(qhat, zkq)
complex qhat
real zkq
qhat = qhat - zkq*qhat
end
--
Trying to get a C testcase.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-26 16:41 ---
C testcase:
_Complex float f(_Complex float a, float b)
{
return a - a*b;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:44 ---
This has been failing since "4.2.0 20060131".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 16:59 ---
Woops what did I do to make this assign this to myself.
Anyways I am no way at all working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I got
[EMAIL PROTECTED] build-i686-linux]$ make install-info DESTDIR=../release
make[1]: Entering directory `/export/build/gnu/gcc/build-i686-linux'
Doing info in gcc
make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/gcc'
make[2]: Nothing to be done for `info'.
make[2]: Leaving d
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-26 17:35 ---
Missing a couple of pieces of info.
How did you configure GCC?
Did you do a build before doing make install-info?
By the way a relative path for DESTDIR will not work so why are you trying to
do that in the first p
rsion 4.2.0 20060526 (experimental)
[dranta:~/tests/gfortran-D] dir% cat write_logical.f90
! PR 14334, L edit descriptor does not work
!
! this test uses L1 and L4 to print TRUE and FALSE
logical true,false
character*10 b
true = .TRUE.
false = .FALSE.
--- Comment #2 from hjl at lucon dot org 2006-05-26 17:57 ---
"make install-info" doesn't work in gcc/intl in 3.4, 4.0, 4.1. But it used to
work in src/intl. After merging intl from gcc to src, "make install-info" no
longers in src/intl.
--
hjl at lucon dot org changed:
W
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-05-26 17:58
---
(In reply to comment #21)
> It is rev 113395 that is causing the problem. I backed out that change and
> built today's version of gfortran - it now correctly runs one of the tests
> that has been failing -
I had
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 17:59 ---
What about 3.3.x? gcc/intl changed in 3.4.x?
Also you still have not said how you configured.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from neroden at gcc dot gnu dot org 2006-05-26 18:34
---
I'm afraid I've become very busy and my priorities have changed; I'm not going
to get this bug fixed. Unassigning.
--
neroden at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #7 from janis at gcc dot gnu dot org 2006-05-26 18:36 ---
A regression hunt on powerpc-linux using the testcase from comment #5 with
--ffast-math identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=107218
r107218 | rguenth | 2005-11-19 11:29:10 +
--- Comment #13 from mueller at gcc dot gnu dot org 2006-05-26 18:39
---
It also causes bootstrap failures (see PR18058)
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 18:41 ---
The problem is here with that patch:
+ if (!FLOAT_TYPE_P (type))
+ arg11 = build_int_cst (type, 1);
+ else
+ arg11 = build_real (type, dconst1);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-26 18:43
---
(In reply to comment #13)
> It also causes bootstrap failures (see PR18058)
Can you try bootstrapping with a newer GCC as that problem should have been
fixed (though the orginally problem in that bug still remains
--- Comment #4 from hjl at lucon dot org 2006-05-26 18:49 ---
I didn't see intl in my gcc 3.3. My gcc is configured with
/net/gnu-13/export/gnu/src/gcc/gcc/configure \
\
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \
\
--enable-shared
--- Comment #23 from dir at lanl dot gov 2006-05-26 19:36 ---
Here is the good and the bad -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -save-temps -o write_logical2
write_logical2.f90
[dranta:~/tests/gfortran-D] dir% write_logical2
At line 9 of file write_logical2.f90
Fortran runtim
We are a team of private investors, with years of good experience
http://209.200.152.115
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-26 19:53 ---
Subject: Bug 23151
Author: tkoenig
Date: Fri May 26 19:53:18 2006
New Revision: 114138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114138
Log:
2006-05-26 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22
---
Subject: Bug 27661
Author: uweigand
Date: Fri May 26 20:21:53 2006
New Revision: 114141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114141
Log:
PR rtl-optimization/27661
* reload.c (find
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-05-26 20:51
---
Looks like .const sections are merged, I will deal with this (it is an one
liner).
Dale thanks for the assembly of both the good and bad.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-05-26 20:52
---
I had wished Apple would care more about the FSF GCC than they are right now.
I still don't understand why an employee of SCEA has to fix their bugs for
them. Maybe Apple should pay me for work I do.
--
http
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-26 21:18
---
Subject: Bug 27524
Author: fxcoudert
Date: Fri May 26 21:18:45 2006
New Revision: 114142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114142
Log:
PR fortran/27524
* trans-array.c (gfc_t
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||4.2.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
The test-case:
// testcase: -
struct A
{
struct B
{
};
};
struct C : A, A::B
{
void foo(B b);
void bar(B* pb);
};
//
==
The error:
foo.cc:11: error: reference to 'B' is ambiguous
foo.cc:5: error: candidate
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-05-27 02:27
---
Actually this is a dup of bug 26427. I had forgot about this issue until now.
*** This bug has been marked as a duplicate of 26427 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-27 02:27 ---
*** Bug 27683 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-05-27 02:35
---
The following patch causes no regressions. I can't reproduce the problem here,
but I have a hunch.
Ray, can you try this and see if it resolves the problem?
Thanks for tests and reports.
Index: io/transfer.c
=
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-27 04:11 ---
Created an attachment (id=11517)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11517&action=view)
patch which fixes part of the problem
This fixes the C testcase but it does not fix the Fortran issue but I don
--- Comment #3 from patchapp at dberlin dot org 2006-05-27 04:30 ---
Subject: Bug number PR25058
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-05/msg01385.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from pault at gcc dot gnu dot org 2006-05-27 05:03 ---
(In reply to comment #12)
> Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0
> on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like
Ah, sorry HJ. You are right.
> But n
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-05-27 05:10
---
Here is some good news. I came up with a test case that fails with gfortran
and passes with intel. The bad news is that I have not fixed it yet. At least
I have something to work with now and its ugly.
program
84 matches
Mail list logo
