--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-01 06:00 ---
Setting to enhancement, as we now detect the error
at runtime.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Compiling gfortran.dg/value_4.f90 with -fdefault-integer-8 gives the following
error:
/opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/value_4.f90:76.6:
if (delta ((3 * i), j)) call abort ()
1
Error: There is no specific function for the generic 'delta' at (1)
gcc version 4.3.0 20070731
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-01 08:21
---
(In reply to comment #1)
This should fix it.
This patch is pre-approved (as well as small variations and improvements of
it), though it might be worth opening an enhancement PR to note that if the
user code has
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2007-08-01
09:55 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
Zdenek, do you have the access to a ppc64 machine to work on the bootstrap
problem?
I do; however, I got stuck with another
--- Comment #22 from victork at il dot ibm dot com 2007-08-01 09:21 ---
Zdenek, do you have the access to a ppc64 machine to work on the bootstrap
problem? Can I provide an useful assistance?
-- Victor
--
victork at il dot ibm dot com changed:
What|Removed
--- Comment #24 from dorit at gcc dot gnu dot org 2007-08-01 10:08 ---
I do; however, I got stuck with another bootstrap problem at the moment
(vectorization changes alignment of variables, which causes a
misscompilation of crtend.o on my machine;
I wonder if this is related to
--- Comment #2 from patchapp at dberlin dot org 2007-08-01 11:05 ---
Subject: Bug number PR32945
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-08/msg00022.html
--
--- Comment #1 from victork at il dot ibm dot com 2007-08-01 11:24 ---
I've tried to build and run SPEC2006 403.gcc using r126903 and it did *not*
fail.
I've used following optimization flags in configuration file:
#
#
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-01 11:57 ---
Ryan, I wonder what happens if you force alignment in the source code, like so:
unsigned short count[MAXBITS+1] __attribute__ ((__aligned__(16))) ;
In this case the vectorizer does not change the alignment of
--- Comment #4 from dorit at gcc dot gnu dot org 2007-08-01 11:36 ---
Also just for the record - the testcase for this PR is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c14
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #16 from pluto at agmk dot net 2007-08-01 11:30 ---
(In reply to comment #15)
(In reply to comment #14)
(In reply to comment #13)
Created an attachment (id=13550)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550action=view) [edit]
An experimental patch
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-08-01 12:53 ---
Subject: Bug 32945
Author: dfranke
Date: Wed Aug 1 12:52:48 2007
New Revision: 127124
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127124
Log:
gcc/fortran:
2007-08-01 Daniel Franke [EMAIL PROTECTED]
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-01 13:51 ---
The first test of PR32770, i.e.:
program main
real, dimension(2) :: a
call random_number(a)
print *,maxloc(a,mask=.true.)
end program main
with -fdefault-integer-8 and your patch, gives (PPC Darwin8):
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-08-01 13:55 ---
Florian, thanks for the report!
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Compiling equiv_7_db.f90 with -fdefault-integer-8 gives:
/opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90:89.38:
data large(1),large(2) /2146435071,-1/
1
Error: Overlapping unequal initializers in EQUIVALENCE at (1)
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-01 14:28 ---
gfortran.dg/minmaxloc_1.f90 gives the same error in my build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
Many failures in the test suite with -fdefault-integer-8 come from tests mixing
C and Fortran. While definitively not an expert in this area, I find pretty
obvious that changing the default integer/real type on one side and not the
other is asking for troubles. Apparently gfortran, but not the
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-01 15:04 ---
At this point, the easiest fix is probably going to be to document
that -fdefault-integer-8 should not be used with bind(c) code. A
check of this option can be inserted at various locations during the
parsing.
--
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-01 15:10 ---
A similar problem occurs with gfortran.fortran-torture/execute/equiv_5.f which
hangs (does not stop, but no CPU time used). The following patch makes the test
pass:
[karma] f90/bug% diff
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c -std=iso9899:1999
-fno-show
-column -E -o c99-tgmath-1.i(timeout = 300)
In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c:7:
--- Comment #1 from ungala_le_babou at hotmail dot com 2007-08-01 15:26
---
I'm making an internship so i cannot change my version of gcc (which 4.1.1).
Since the bug is still unconfirmed, I wonder if it was fixed in the latest
version of gcc...
--
ungala_le_babou at hotmail dot
--- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36 ---
I have had a nonexpert look at the patch and I wonder if
+ ts.kind = gfc_default_logical_kind;
should not be
+ ts.kind = newkind;
???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
My build of gcc fails with an error running msgfmt. If I do
/usr/bin/msgfmt --statistics libcpp/po/fr.po -o /dev/null
I get failure with the current gcc (rev 127119) but if I use the file fr.po
from rev 111982 the command works. Does the fix need to happen to fr.po or to
my msgfmt binary? I
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-01 16:53 ---
Subject: Bug 32919
Author: drow
Date: Wed Aug 1 16:53:01 2007
New Revision: 127132
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127132
Log:
PR tree-optimization/32919
* tree-ssa-sccvn.c
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-01 16:58 ---
This is fixed now.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from danglin at gcc dot gnu dot org 2007-08-01 16:30
---
A similar error appeared in revision 127096 on hppa-unknown-linux-gnu:
/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h: In
fu
nction '_ForwardIterator std::__search_n(_ForwardIterator,
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-01 17:16 ---
(In reply to comment #5)
I have had a nonexpert look at the patch and I wonder if
+ ts.kind = gfc_default_logical_kind;
should not be
+ ts.kind = newkind;
Yes, I believe you are correct.
--- Comment #17 from danglin at gcc dot gnu dot org 2007-08-01 17:27
---
Looking at the hpux failure, it seems
_ZSt8search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT
1_T2_ is miscompiled.
The problem is probably the same as reported in PR32878.
--
--- Comment #2 from kargl at gcc dot gnu dot org 2007-08-01 17:29 ---
These two examples are the poster child for
1) Why -fdefault-integer-8 is a bad option and should only be
used by people who are prepared to have broken results.
2) Why EQUIVALENCE is a horribly abused construct.
--- Comment #9 from pluto at agmk dot net 2007-08-01 17:37 ---
(In reply to comment #7)
i have tracked down module by module of the kernel
and after all i found the module which caused the
kernel crash - its arch/i386/kernel/i8259.c
diffing assembly dumps for these objects shows
--- Comment #7 from tkoenig at alice-dsl dot net 2007-08-01 17:46 ---
Subject: Re: mask and -fdefault-integer-8
On Wed, 2007-08-01 at 15:36 +, dominiq at lps dot ens dot fr wrote:
--- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36
---
I have had a
Compile this:
extern void f(void);
extern void g(void) __attribute__ ((hot)) __attribute__((cold));
extern void f(void) __attribute__ ((hot));
extern void f(void) __attribute__ ((cold));
I see a warning for the conflicting attributes on 'g', but not
for 'f'. The problem here is that the
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-01 17:55 ---
Subject: Bug 32936
Author: burnus
Date: Wed Aug 1 17:55:24 2007
New Revision: 127135
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127135
Log:
2007-08-01 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:00 ---
FIXED in GCC 4.3; as it is not regression [and no wrong-code bug either] I will
not backport it to 4.2.x or 4.1.x - mark as fixed.
Note: GCC gfortran 4.3.0 nightly builds are e.g. available at
I have some code that uses _mm_slli_epi32 intrinsics and some other shift ones.
This code compiles fine in GCC 4.1/4.0 and ICC 9.1.
I tried compiling it with GCC 4.2 and I get the error
testt.c:4: error: shift must be an immediate
_mm_slli_epi32 is defined as:
__m128i _mm_slli_epi32 (__m128i m,
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-08-01 18:49 ---
Even with the correction, the patch didn't pass regression-testing.
It's a good thing we do this.
I'll continue my investigations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #1 from mikelikespie at gmail dot com 2007-08-01 18:50 ---
I forgot to mention, I'm running the latest gentoo with amd64, and gcc (GCC)
4.2.0 (Gentoo 4.2.0 p1.4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-01 19:05 ---
With the change my tests now compile (regtesting!-), but
gfortran.dg/zero_sized_1.f90 aborts.
BTW I don't understand the error:
Can't convert LOGICAL(8) to LOGICAL(8) at (1)
How can a no operation trigger an
--- Comment #11 from dominiq at lps dot ens dot fr 2007-08-01 19:11 ---
The problem is with PACK. If I comment the line
call test_pack
the test pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #10 from axel at freakout dot de 2007-08-01 19:25 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
diffing assembly dumps for these objects shows that
4.2 output doesn't contain
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 ---
Actually, two lines suffice:
templateunsigned x static inline void f() { }
template inline void f5() { }
This also breaks inkscape.
--
falk at debian dot org changed:
What|Removed
--- Comment #13 from dominiq at lps dot ens dot fr 2007-08-01 20:17 ---
I still have the Bus error. From the backtrace I think the culprit is
libgfortran/intrinsics/pack_generic.c. Probably around the lines:
pack_internal (gfc_array_char *ret, const gfc_array_char *array,
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-01 20:01 ---
Confirmed with 4.3.0 of today on PPC Darwin8:
original = ( 2.00 , 0.00 ) (
3.00 , 0.00 ) ( 7.00 ,
0.00 ) (
--- Comment #1 from wirawan0 at gmail dot com 2007-08-01 20:00 ---
Created an attachment (id=14006)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14006action=view)
Failing testcase with higher-dimensional b array
I found that the result of conjg(transpose(a)) is also wrong if b is
--- Comment #1 from sje at cup dot hp dot com 2007-08-01 19:54 ---
Created an attachment (id=14005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14005action=view)
test program that will ICE at -O2
Attached is a Fortran test program that will ICE if compiled at -O2 on IA64.
--
--- Comment #5 from nathan at gcc dot gnu dot org 2007-08-01 19:42 ---
The standard is unclear about exactly why this is ill-defined. Does the
conversion operator take part in overload resolution (and then be rejected, if
it is selected), or is it never entered into the overload set.
It turns out that bug #31994
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994) has not been fully
resolved!
I found another testcase that would fail gcc 4.2.1, namely if the destination
of the expression is an allocatable array. Use the following testcase:
program testcase
complex(kind=8),
I believe this is due to the new floating point division code that I put it in.
I am looking at changing the convert functions in div.md back to UNSPECs and I
believe this will fix the problem. I will attach a test program.
--
Summary: ICE in failed_reload, could not find a spill
--- Comment #3 from wirawan0 at gmail dot com 2007-08-01 20:02 ---
Created an attachment (id=14007)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14007action=view)
Magically successful testcase!
And by the way, if BOTH b and a are part of higher-dimensional arrays (see
testcase),
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-08-01 20:44
---
(In reply to comment #13)
I still have the Bus error. From the backtrace I think the culprit is
libgfortran/intrinsics/pack_generic.c. Probably around the lines:
Hi Dominique,
I just committed a corrected
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-08-01 20:27
---
Subject: Bug 32954
Author: tkoenig
Date: Wed Aug 1 20:27:27 2007
New Revision: 127137
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127137
Log:
2007-08-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #16 from dominiq at lps dot ens dot fr 2007-08-01 21:19 ---
As far as I can tell, I have applied correctly your latest patch. But the
following reduced test
! { dg-do run }
! Transformational functions for zero-sized array and array sections
! Contributed by Francois-Xavier
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-01 21:29 ---
(In reply to comment #5)
Actually, two lines suffice:
I don't remember if template functions can be static. I really think they
cannot.
Which is one of the reasons why this bug was not marked as confirmed or have
Testcase:
union A
{
float a;
};
float t(float a)
{
union A a1, a2, a3;
a1.a = a;
for(int i =0;i100;i++)
{
a2 = a1;
a2.a += a;
a1 = a2;
}
a3 = a1;
return a3.a;
}
--
We currently get on powerpc-linux-gnu in the inner loop:
.L2:
stw 0,8(1)
lfs 0,8(1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-01 23:16 ---
Hmm, the trunk is worse than the 4.2 branch for -msse2 -mfpmath=sse.
Trunk:
.L2:
movss -4(%ebp), %xmm1
addl$1, %eax
cmpl$100, %eax
addss %xmm0, %xmm1
movss
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-01 23:18 ---
One should note the original testcase included a vector float and a struct
inside the union and used C++, this is just a reduced testcase of the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
--- Comment #1 from daney at gcc dot gnu dot org 2007-08-02 00:38 ---
Still happens in: revision 127079
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-02 00:37 ---
Created an attachment (id=14008)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14008action=view)
Patch which needs full testing still
Hi, this reverts Jeff's patch in both stmt.c and cfgexpand.c (I don't know
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-02 00:31 ---
.L4:
slwi 0,3,2
lwzx 0,9,0
add 3,3,4
addi 4,4,-1
bdnz .L4
Much better correct?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #30 from lauras at gcc dot gnu dot org 2007-08-02 01:13 ---
For the record, this was caused by obsolete awk version, please upgrade if you
experience this problem. The need to document awk prerequisite is tracked in
PR 30739.
--
lauras at gcc dot gnu dot org changed:
--- Comment #31 from lauras at gcc dot gnu dot org 2007-08-02 01:14 ---
Closing.
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-02 02:17 ---
Yeah -- I looked at the other bugs before filing this one.
The issue here is that the hot/cold code already checks for the conflict;
but we merge without calling the handlers, so the check is never triggered.
I
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:10 ---
I have filed other bug reports about stuff like this, we currently accept
noinline and alwaysinline which are more conflicting than hot and cold.
--
pinskia at gcc dot gnu dot org changed:
What
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html shows -ftree-dse as an
optimization enabled by -O / -O1, but doesn't document it below.
via http://tinyurl.com/3cdlnu
Per tree-ssa-dce.c:
A dead store is a store into a memory location which will later be
overwritten by another store without
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-08-02 02:57 ---
Subject: Bug 32668
Author: ghazi
Date: Thu Aug 2 02:57:26 2007
New Revision: 127146
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127146
Log:
gcc/cp:
PR middle-end/32668
* call.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:33 ---
Confirmed. This was listed on PR 13756.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This:
#includecstdlib
class system { system() {} };
int foo(system* p) {}
gets you:
~/ootbc/systemspec/build$ g++ foo.cc
foo.cc:4: error: 'p' was not declared in this scope
foo.cc:4: error: expected ',' or ';' before '{' token
The problem is that the function int system(...) is in scope so
--- Comment #1 from igodard at pacbell dot net 2007-08-02 05:32 ---
Doh! a constructor. Sorry to trouble you.
--
igodard at pacbell dot net changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 05:42 ---
Confirmed.
Paul, I'm putting you on the CC list because you fixed
PR 31994, the original conjg(transpose()) bug. Maybe
you can do something about this one :-)
Thomas
--
tkoenig at gcc dot gnu dot org changed:
69 matches
Mail list logo
