--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-10 07:12 ---
With 4.3.0 20070404/x86_64-unknown-linux-gnu I don't get the ICE - and no
problem is discovered using valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-10 07:41 ---
I can reproduce the crash with GCC/gfortran 4.1, but not with 4.2 or 4.3.
GCC 4.3 is the current developer version which gets all the fixes. GCC 4.2 and
4.1 are open only for regressions; some of the fixes are also
it seems the code which notices things like assert(x 0) to help
strength-reduce division to shifts doesn't help if the divide is inside a loop.
for example:
% cat idiv-assert.c
void fail(void) __attribute__((noreturn));
int bar(int);
int foo(int x) {
int i;
int s = 0;
if (x = 0) fail();
Compile this with -O2 -W -Wall and you should not get a warning but you get an
overflow warning which is a false positive as this condition can never be false
even with overflow (as shown by doing -Dint=unsigned):
int bar(int);
int f(int x)
{
int y;
if (x=4) y = 1;
else y = x/4;
return y
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-10 08:28 ---
Also now I think this is a 4.2 regression but I don't have 4.2 checked out on
this machine so I cannot check.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-10 08:30 ---
Note this was found while looking into PR 31521.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31522
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-10 08:39 ---
i_5 = ASSERT_EXPR i_1, i_1 x_10;
D.1607_6 = i_5 / 4;
i_5: [0, 2147483646] EQUIVALENCES: { i_1 } (1 elements)
We don't do the shifting if i's range includes 0 which is wrong as 0n is
always 0 so the reduced
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-10 08:56 ---
IR after assert insertion (plus annotate with ranges found):
f (x)
{
int y;
int D.1599;
bb 2:
if (x_2(D) = 4) goto L2; else goto L1;
L1:;
x_7 = ASSERT_EXPR x_2(D), x_2(D) 4; // x_7: [5, +INF]
y_4 = x_7
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-10 08:58 ---
Patch which I need to test (but I won't have time until Thursday).
Index: tree-vrp.c
===
--- tree-vrp.c (revision 123691)
+++ tree-vrp.c (working
--- Comment #7 from pault at gcc dot gnu dot org 2007-04-10 09:28 ---
(In reply to comment #6)
Tobi,
(trans-expr.c:141) which looks like it gets the types right. Replacing the
call to fold_convert with an equivalent call to build_int_cst doesn't help
either, BTW.
Does casting the
--- Comment #3 from dean at arctic dot org 2007-04-10 09:38 ---
nice... that seems to do the trick on idiv-assert.c:
10: 89 df mov%ebx,%edi
12: 83 c3 01add$0x1,%ebx
15: c1 ff 02sar$0x2,%edi
18: e8 00 00 00 00
Bootstrap of gcc-4.1.2 failed with an internal compiler error
(Please submit a full bug report) from ./gcc/xgcc when compiling
libstdc++-v3/libsupc++/del_op.cc, using gcc-3.4.3 as the bootstrap
compiler on sparc-sun-solaris2.6 with following configure options
and bootstrap flags (below), producing
gcc = 3.x emits wrong warning for assignment of bool=non-bool=value;
for bool=bool=value, no warning is emitted, which is fine.
$ for i in 2.95 3.4 4.0 4.1 4.2-HEAD 4.3-HEAD;do echo # gcc-$i:;echo -e
#include stdbool.h\nint i;bool b;int main(void){b=i=false;return b;} |
gcc-$i -xc - -o boo
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-10 10:36 ---
I have no plans to address this (it was Dirk who added the testcases), let's
fix
PR 12535 (finally) instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from amylaar at gcc dot gnu dot org 2007-04-10 10:58 ---
(In reply to comment #2)
See the thread: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01267.html.
I don't know what happened to it.
This is the latest version of the patch:
--- Comment #14 from mark at gcc dot gnu dot org 2007-04-10 11:02 ---
Assuming other mark should be CCed to make 4.2 decision.
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paolo at gcc dot gnu dot org 2007-04-10 11:39 ---
Subject: Bug 28277
Author: paolo
Date: Tue Apr 10 11:38:50 2007
New Revision: 123692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123692
Log:
2007-04-10 Paolo Carlini [EMAIL PROTECTED]
PR
Fails on 4.1.2 and 3.4.2. Works on 3.2.2
When compiling the following code:
template class _T class A {
protected:
int b;
};
template class _T class B : public A_T {
public:
void test_ok() {
this-b = 17;
}
void test_fail() {
b =
--- Comment #1 from edufer at gmail dot com 2007-04-10 12:26 ---
Created an attachment (id=13342)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13342action=view)
Sample code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31525
=release
Thread model: posix
gcc version 4.3.0 20070410 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1plus
-fpreprocessed bug.ii -quiet -dumpbase bug.ii -mtune=generic -auxbase bug -O
-version -o /tmp/ccx57rja.s
GNU C++ version 4.3.0 20070410 (experimental) (i686-pc
--- Comment #2 from pcarlini at suse dot de 2007-04-10 12:50 ---
This is conforming behavior, implemented for the first time in the 3.4.x
release series:
http://gcc.gnu.org/gcc-3.4/changes.html
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #1 from martin at mpa-garching dot mpg dot de 2007-04-10 12:54
---
Created an attachment (id=13343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13343action=view)
unreduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-10 13:07 ---
Zdenek, this is likely caused by your patch (same bug as for tramp3d).
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-04-10 13:10 ---
Most likely (although probably it just exposes an existing bug, some pass
forgets to clean up aux after using it).
--
rakdver at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from edufer at gmail dot com 2007-04-10 13:28 ---
(In reply to comment #2)
This is conforming behavior, implemented for the first time in the 3.4.x
release series:
http://gcc.gnu.org/gcc-3.4/changes.html
Correct. Many thanks for your time.
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-10 13:39 ---
I don't see the warning, but the range with overflow is derived from
vrp_visit_phi_node where we fall back to +INF(OVF) from [1, 536870911] because
/* To prevent infinite iterations in the algorithm, derive
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-04-10 13:59 ---
This patch fixes the problem:
Index: tree-inline.c
===
*** tree-inline.c (revision 123693)
--- tree-inline.c (working copy)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-10 14:08 ---
Created an attachment (id=13344)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13344action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
--- Comment #6 from eweddington at cso dot atmel dot com 2007-04-10 14:11
---
Danny,
Can you take a look at this bug and the corresponding patch in comment #5? This
issue has been around a long time, and the fix has worked for a long time too.
It would be nice if the fix could be
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-10 14:15 ---
There's one missed FRE opportunity in that we do not value-number
VIEW_CONVERT_EXPR__v16qi(D.6423) the same. This is because VIEW_CONVERT_EXPR
is tcc_reference I believe.
Created value VH.19 for VH.17.VH.18 vuses:
Related to PR 448 and PR 16989.
The C 99 standard includes complex.h, however, Cygwin does not provide it.
Expected: GCC provides complex.h on platforms lacking it.
Cf. http://gcc.gnu.org/ml/fortran/2007-04/msg00100.html
--
Summary: Provide complex.h for cygwin platform (C99
The inlining performed with -Os has often a tendency to
increase the code size for the AVR target, so it misses the
entire point behind using -Os.
This might be related to bug #30908.
--
Summary: Inlining with -Os increases code size
Product: gcc
Version: 4.1.2
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-10 14:37 ---
Reduced testcase:
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef long long __v2di __attribute__ ((__vector_size__ (16)));
typedef char __v16qi __attribute__
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-10 14:38
---
Created an attachment (id=13345)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13345action=view)
Test case for bug 66690.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-04-10 14:40
---
Created an attachment (id=13346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13346action=view)
Generated assembly code with -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-04-10 14:40
---
Created an attachment (id=13347)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13347action=view)
Generated assembly code with -Os -fno-inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #14 from davek at gcc dot gnu dot org 2007-04-10 15:11 ---
Patch posted for review at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-10 15:13 ---
I have a patch, but I want to fix the related PR30871 at the same time.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-04-10 15:32 ---
store_copyprop is not able to optimize this because the two array refs
r.dst[0].i use different types for the index zero (one int, one unsigned long)
and one has operand2 and operand3 set but the other not and
--- Comment #18 from giovannibajo at libero dot it 2007-04-10 15:34 ---
(In reply to comment #15)
Yes, the tendency to handle far too many items as 16 bits (the
sizeof(int) on that machine) when 8 bits would suffice is one of the
major issues the AVR-GCC users have with the
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-04-10 15:38
---
This code snippet can also be run through the i386 compiler (even though
the generated code will obviously be nonsensical). I've only got an older
version of that compiler at hand:
gcc41 (GCC) 4.1.2 20061229
--- Comment #7 from oliver at linux-kernel dot at 2007-04-10 15:44 ---
Same problem happens on alpha. read_barrier is not defined in sysdeps/locks.h.
Added read_barrier with a simple __sync_synchronize, but I guess this will not
work in real life... Just for testing... Can please check
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-10 16:14 ---
I have to look this up, but complex.h might not be required to be provided by a
freestanding compiler (which is what we consider GCC to a point).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31527
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-10 16:38 ---
Inlining decisions are based on heuristics. What works for one target may not
work quite as well for another. In this case, it seems that for AVR the
heuristics are not the best. You can tune the heuristics for this
--- Comment #6 from patchapp at dberlin dot org 2007-04-10 16:40 ---
Subject: Bug number PR31293
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-04/msg00070.html
--
--- Comment #15 from patchapp at dberlin dot org 2007-04-10 16:41 ---
Subject: Bug number PR14331
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-04/msg00457.html
--
--- Comment #8 from aph at gcc dot gnu dot org 2007-04-10 16:47 ---
I don't have an Alpha to test, but I can see read_barrier() in HEAD:
inline static void
read_barrier()
{
__asm__ __volatile__(mb : : : memory);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30424
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-04-10 16:55 ---
Created an attachment (id=13348)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13348action=view)
patch
Actually that breaks with some hashing. I have a slightly different approach
in
testing now. We are
--- Comment #9 from oliver at linux-kernel dot at 2007-04-10 17:11 ---
(In reply to comment #8)
I don't have an Alpha to test, but I can see read_barrier() in HEAD:
inline static void
read_barrier()
{
__asm__ __volatile__(mb : : : memory);
}
OK and write_barrier() still is
--- Comment #10 from aph at gcc dot gnu dot org 2007-04-10 17:14 ---
I don't know what you're asking. It's fixed in HEAD, and it's fixed in Fedora
development.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30424
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-04-10 17:15
---
(In reply to comment #5)
Inlining decisions are based on heuristics. What works for one
target may not work quite as well for another. In this case, it
seems that for AVR the heuristics are not the best.
--- Comment #11 from oliver at linux-kernel dot at 2007-04-10 17:23 ---
Andrew. It's OK. write_barrier() is fine in Fedora Development. But
read_barrier() is missing in libjava/sysdep/alpha/lock.h. Just forget it :-)
Thx!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30424
/ --with-mpfr=/opt/i686/mpfr-2.2.1
--disable-multilib --enable-intermodule i686-linux-gnu
Thread model: posix
gcc version 4.3.0 20070410 (experimental)
Gives:
[snip]
../../../src/gcc-4.3/gcc/config/i386/i386.c -o libbackend.o \
-DBASEVER=\4.3.0\ -DDATESTAMP=\ 20070410\ \
-DDEVPHASE
--- Comment #15 from mmitchel at gcc dot gnu dot org 2007-04-10 18:05
---
Yes, this is OK for 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-10 18:07 ---
--enable-intermodule is the key.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
With -O1 -frounding-math on x86, the following function
double f(double a, double b, double c)
{ return a * -b + c; }
is compiled as
fldl16(%ebp)
fmull 8(%ebp)
fsubrl 24(%ebp)
So the body of the function has been rewritten as c - a * b. This
/* Given X an unsigned of 32 bits, and Y a bool. Try to translate optimizing
*
* Y = X 2147483647; to Y = ((signed)X) 0;
* Y = X = 2147483648; to Y = ((signed)X) 0;
*
* [ Another optimization is to Y = (X 31) ]
*
* The opposite (ELSE):
*
* Y = X = 2147483647; to Y = ((signed)X) =
--- Comment #1 from JCPiza at gmail dot com 2007-04-10 19:14 ---
Created an attachment (id=13349)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13349action=view)
isnegative, a wonderful test of equivalence for uoptimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-10 19:17 ---
What the real issue is that we don't fold !(x = 0) into x 0 before
expanding.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-04-10 19:18 ---
(In reply to comment #2)
Maybe you don't have checking enabled for the release versions?
That appears to be the case (I thought I had set --enable-checking).
In any case, I see the ICE on the currently maintained
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-10 19:20 ---
A quick patch like:
Index: expr.c
===
--- expr.c (revision 123691)
+++ expr.c (working copy)
@@ -6828,7 +6828,7 @@
tree type;
int
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-10 19:26 ---
Accept. I somehow missed the email/PR while reading all the messages after a
conference.
Patch at:
http://gcc.gnu.org/ml/fortran/2007-04/msg00105.html
(In reply to comment #1)
xlf yields a bus error without
--- Comment #2 from vivekrao4 at yahoo dot com 2007-04-10 19:38 ---
This bug was discussed in a Feb 2006 thread suggestion regarding spurious(?)
internal error message
http://gcc.gnu.org/ml/fortran/2006-02/msg00445.html . No one in that thread
said they submitted it to bugzilla.
--
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-04-10 20:58
---
Created an attachment (id=13350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13350action=view)
Sample implementation
This is how I would the implementation of minloc to behave,
shown as a sample
--- Comment #7 from j at uriah dot heep dot sax dot de 2007-04-10 21:04
---
Changed target triplet from avr-*-* to *-*-* as obviously, at least some
of GCC's mainstream targets are affected by that bug as well (perhaps
even *any* target).
--
j at uriah dot heep dot sax dot de
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-04-10 21:11 ---
(In reply to comment #8)
Created an attachment (id=13348)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13348action=view) [edit]
patch
for one part we only set operands 2 and 3 if they are not
Hi,
the attached code suggests that the implementation does not
conform to the F2003 standard w.r.t. the POSITION= specifier.
The standard says:
9.9.1.22 POSITION= specifier in the INQUIRE statement
[...]
If the file has been repositioned since the connection, the
--- Comment #1 from anlauf at gmx dot de 2007-04-10 21:35 ---
Created an attachment (id=13351)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13351action=view)
Test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31532
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-10 21:38
---
Indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #43 from anlauf at gmx dot de 2007-04-10 21:40 ---
(In reply to comment #42)
In my attempts at narrowing down I found a (minor) problem
with INQUIRE, see PR 31532. Will continue on this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-04-10 22:03 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00486.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rakdver at gcc dot gnu dot org 2007-04-10 22:10 ---
Subject: Bug 31526
Author: rakdver
Date: Tue Apr 10 22:10:26 2007
New Revision: 123699
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123699
Log:
PR tree-optimization/31526
* tree-inline.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-10 22:50 ---
This is fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
[...]
make[2]: Leaving directory `/tmp/build-gcc/i686-pc-linux-gnu/libssp'
make[2]: Entering directory `/tmp/build-gcc/i686-pc-linux-gnu/libgfortran'
/bin/sh ../../../gcc-4.1.2/libgfortran/mk-kinds-h.sh
'/tmp/build-gcc/./gcc/gfortran -B/tmp/build-gcc/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-10 23:40 ---
This usually means your GMP/MPFR is broken and not working correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from vivekrao4 at yahoo dot com 2007-04-10 23:51 ---
It appears that spurious ICE messages are a general problem with GCC. The site
Managing Bugs (Bugzilla and the testsuite) at
http://www.gnu.org/software/gcc/bugs/management.html says
'Bugs with keyword
--- Comment #3 from spop at gcc dot gnu dot org 2007-04-11 01:09 ---
Subject: Bug 31343
Author: spop
Date: Wed Apr 11 01:09:35 2007
New Revision: 123708
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123708
Log:
PR tree-optimization/31343
* tree-chrec.h
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-11 03:46 ---
complex.h and complex support is not required for freestanding compilers which
is what GCC is really. Yes it can be considered a non free standaing one but
that means it needs library support which is got from the
--- Comment #15 from eweddington at cso dot atmel dot com 2007-04-11 04:20
---
Bernd, Rolf,
Can you verify if this bug still exists? If so, I have in my notes that this
patch will fix this bug:
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-11 06:34 ---
It turns out you have to add -Wstrict-overflow to get the warning but this is
still a false warning.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
81 matches
Mail list logo
