--- Comment #7 from martsummsw at hotmail dot com 2006-08-27 06:37 ---
I am the reporter of this bug (with a new email-adress)
This problem seems to be solved with 4.1.1 =)
(Consider only #5 and forward - the first is wrong/irrelevant)
--
martsummsw at hotmail dot com changed:
--- Comment #4 from ian at airs dot com 2006-08-27 06:44 ---
I disagree. It is always useful to optionally warn about meaningless code. It
can be a way to find a real bug in the program. It is not conceptually
different from existing warnings like -Wredundant-decls. The code works
--- Comment #2 from fang at csl dot cornell dot edu 2006-08-27 07:45
---
Looks recently fixed by patch for PR 28659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28863
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-08-27 10:51 ---
The problem is still visible on the mainline, unrolling the loop on the tree
level pessimizes the generated code. Zdenek, maybe you can have a look at this
(testcase in comment #5).
--
rguenth at gcc dot gnu
--- Comment #6 from h dot mth at web dot de 2006-08-27 12:31 ---
After some testing I can say that this is caused by the fix to bug 27529.
--
h dot mth at web dot de changed:
What|Removed |Added
--- Comment #14 from tbm at cyrius dot com 2006-08-27 13:20 ---
Bootstrapped and regtested successfully on mipsel-linux-gnu and
x86_64-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
--- Comment #9 from martsummsw at hotmail dot com 2006-08-27 13:21 ---
Hmmm - I am (also) wrong when I claimed it was solved in 4.1.1. It is improved
since the example that goes wrong in #5 now is right, but it is just
the limit (for when the compiler gets comfused) that is pushed a
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-08-27 14:20
---
So I have a patch that produces (diff typedef long GLint
__attribute__((may_alias)) resunts vs. patch):
--- t.i.030t.alias1.ok 2006-08-27 16:13:54.0 +0200
+++ t.i.030t.alias1 2006-08-27
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-08-27 14:56
---
(In reply to comment #8)
The problem is still visible on the mainline, unrolling the loop on the tree
level pessimizes the generated code. Zdenek, maybe you can have a look at
this
(testcase in comment #5).
--- Comment #1 from paolo at gcc dot gnu dot org 2006-08-27 15:19 ---
Subject: Bug 28830
Author: paolo
Date: Sun Aug 27 15:19:23 2006
New Revision: 116489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116489
Log:
2006-08-27 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-27 15:22
---
Subject: Bug 26573
Author: lmillward
Date: Sun Aug 27 15:22:05 2006
New Revision: 116490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116490
Log:
PR c++/26573
* class.c
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-27 15:22
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2006-08-27 15:23 ---
Fixed. In case, we can always add something more specific for the _S_lockfree
base (in any case gets already testing on every ia64, powerpc, alpha, s390...).
--
pcarlini at suse dot de changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 15:41 ---
You must have something backported to 4.1.x because the patch which orginally
caused this was only on the mainline.
*** This bug has been marked as a duplicate of 28659 ***
--
pinskia at gcc dot gnu dot org
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-27 15:41
---
*** Bug 28863 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-08-27 15:41
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
by noticing that if pt_anything is set, we indeed need to include all
addressable vars in the clobbering:
This is also equivalent
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-08-27 15:49
---
Well, yes. If we still had pt_vars at the time of add_call_clobber_ops () we
might only do it if one of the actual params of a CALL_EXPR has pt_anything
set.
But call clobbering is not per call-site or
--- Comment #23 from dberlin at gcc dot gnu dot org 2006-08-27 16:00
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-08-27 15:49
---
Well, yes. If we still had pt_vars at the time
--- Comment #13 from serzholino at gmail dot com 2006-08-27 16:20 ---
Confirmed with qt4 on win32
--
serzholino at gmail dot com changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2006-08-27 17:44 ---
All diagnostics about meaningless attributes are currently warnings. I'm not
going to change this one to be different from the others.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-08-27 17:45
---
Subject: Bug 28058
Author: mmitchel
Date: Sun Aug 27 17:45:25 2006
New Revision: 116491
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116491
Log:
PR c++/28058
* pt.c
--- Comment #24 from drow at gcc dot gnu dot org 2006-08-27 17:56 ---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
On Sun, Aug 27, 2006 at 04:00:19PM -, dberlin at dberlin dot org wrote:
1. You believe this is a good idea for 4.2, even though it
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-08-27 18:00
---
Subject: Bug 28058
Author: mmitchel
Date: Sun Aug 27 17:59:55 2006
New Revision: 116492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116492
Log:
PR c++/28058
* pt.c
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-08-27 18:00
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from tbm at cyrius dot com 2006-08-27 18:30 ---
(In reply to comment #14)
Steve Ellcey posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html
I posted a better patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html
This
For bootstrapping gcc 3.4.6 I have configured it the follwing way:
env CONFIG_SHELL=/bin/ksh /usr/local/tmp/gcc-3.4.6/configure
--prefix=/usr/local --with-ld=/usr/bin/ld --with-as=/usr/bin/as
--enable-languages=c
Building (using GNU make) then ends up like this:
if [ -f specs.ready ] ; then \
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-27 18:45 ---
We get:
.L66:
fldl-40(%ebp)
faddl (%esi,%eax,8)
addl$1, %eax
cmpl%edx, %eax
fstpl -40(%ebp)
jne .L66
Now on the mainline
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-27 18:50 ---
Actually this is a bug in the make version you are using because a SHELL inside
make should and will always be a sh-compatible shell.
Also this works for me as I use the tcsh as my shell.
One more question, since
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-27 18:59 ---
Part of the problem here is that 4.0 removed addressof but that does not
explain why 3.4.0 could not do this optimization.
Maybe one of the problems is that we are no lowering memcpy at the tree level
into VCE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 19:00 ---
For PPC, we get:
stw 3,-16(1)
stw 3,48(1)
nop
nop
lfs 1,-16(1)
blr
Notice the extra store, that does not need to be there.
--
pinskia at gcc dot gnu dot org
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-08-27 19:02
---
I agree with Daniel's comments in Comment #9.
The only reliable fix is to commit to unit-at-a-time, always, for all
languages, independent of optimization. Then, after we decide what to emit
(cgraph), we can
--- Comment #2 from georg dot schwarz at freenet dot de 2006-08-27 19:04
---
Subject: Re: bootstrapping fails when building from non-/bin/sh-compatible
shell
Am 27.08.2006 um 20:50 schrieb pinskia at gcc dot gnu dot org:
--- Comment #1 from pinskia at gcc dot gnu dot org
--- Comment #11 from martsummsw at hotmail dot com 2006-08-27 19:33 ---
You are right =)
I recall I did play with some params in 3.4, but without result but I did
not in 4.0 - since I did not expect a so (in my head) fairly low number to be
large ...
It would be real nice if gcc
I get the following error when building gcc 3.4.6 as a
cross compiler for x86_64 on an IA32 box.
I searched the crossgcc and gcc-bugs mail archives,
but found no reference to a similar problem.
Any know whats going wrong here? Both pthread.h and
unistd.h are present in /usr/include on the host.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-27 20:18 ---
This works for me on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from mmitchel at gcc dot gnu dot org 2006-08-27 20:25
---
Dan Berlin believes that Richard's patch in Comment #20 is the conservative
fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--- Comment #26 from mmitchel at gcc dot gnu dot org 2006-08-27 20:28
---
I don't understand how TBAA is interacting with the may-alias information.
In particular, TBAA doesn't say anything about casts; it says something about
loads and stores. In particular, TBAA forbids accessing
--- Comment #27 from dberlin at gcc dot gnu dot org 2006-08-27 20:51
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
I don't understand how TBAA is interacting with the may-alias information.
Given a pointer, and some aliases, we ask TBAA, for each
--- Comment #38 from pinskia at gcc dot gnu dot org 2006-08-27 21:07
---
For the reduced testcase in comment #12, we get:
.L2:
movl8(%ebp), %edx
movl-4(%edx,%ecx,4), %eax
movl%eax, (%esi)
movl16(%ebp), %edi
movzbl -1(%ecx,%edi),
--- Comment #28 from dberlin at gcc dot gnu dot org 2006-08-27 21:09
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
Since we have never done that before, it does require new code.
And to answer what may be a followup, which is why hasn't this
--- Comment #14 from dannysmith at users dot sourceforge dot net
2006-08-27 21:14 ---
(In reply to comment #12)
This happens with Qt4 Win32 as well - lot of warnings - warning: inline
function... attribute ignored. All that's needed is a -Wno-inline-dllimport
type of flag to mingw
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-27 21:32 ---
On the mainline we get a different ICE now:
[EMAIL PROTECTED] gcc]$ ~/gcc-local//bin/gcc t.c
t.c: In function foo:
t.c:4: internal compiler error: in force_constant_size, at gimplify.c:709
Please submit a full bug
--- Comment #8 from ian at gcc dot gnu dot org 2006-08-27 21:43 ---
Subject: Bug 28797
Author: ian
Date: Sun Aug 27 21:42:55 2006
New Revision: 116493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116493
Log:
PR other/28797
* cp-demangle.c
--- Comment #9 from ian at airs dot com 2006-08-27 21:44 ---
I'm going to close this PR since I just fixed the only real problem that I see
here. If you see other problems with the demangler, please open a separate PR
for each problem.
Thanks for reporting the bug.
--
ian at airs
For example this C:
struct {int x; int y[];} obj = {1, {2, 3}};
produces this assembly:
.globl obj
.data
.align 4
.type obj, @object
.size obj, 4
obj:
.long 1
.long 2
.long 3
.size should include the flexible array component.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-27 21:59 ---
I bet this comes down to MOVE_RATIO changing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from qrczak at knm dot org dot pl 2006-08-27 22:15 ---
A question: when this is fixed, what should be C-level sizeof obj?
I hope it would include the flexible array component. This would allow to
detect in autoconf whether this bug is fixed, and would be consistent with
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-27 22:32 ---
Janis,
Can you do a regression hunt on this bug?
I almost think it was caused by revision 112408.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following program fails to compile because the commit
noted in the comment broke the processing of a chain of
matchers.
! { dg-do compile }
! Test fix for regression caused by
! 2006-06-23 Steven G. Kargl [EMAIL PROTECTED]
!PR fortran/27981
!* match.c (gfc_match_if): Handle
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-27 22:44 ---
Since I have a patch, I might as well confirm the bug.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-27 23:12 ---
I have a simple fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ian at airs dot com 2006-08-27 23:23 ---
I'll take this.
--
ian at airs dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 23:23 ---
The patch which I am testing:
Index: call.c
===
--- call.c (revision 116493)
+++ call.c (working copy)
@@ -4544,10 +4544,12 @@ build_x_va_arg
--- Comment #12 from ian at gcc dot gnu dot org 2006-08-27 23:50 ---
Subject: Bug 27622
Author: ian
Date: Sun Aug 27 23:50:30 2006
New Revision: 116494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116494
Log:
PR driver/27622
* pex-common.h (struct pex_funcs):
--- Comment #13 from ian at gcc dot gnu dot org 2006-08-28 00:00 ---
Subject: Bug 27622
Author: ian
Date: Mon Aug 28 00:00:30 2006
New Revision: 116495
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116495
Log:
PR driver/27622
* pex-common.h (struct pex_funcs):
--- Comment #14 from ian at airs dot com 2006-08-28 00:02 ---
Fixed in mainline and 4.1 branch.
As far as I can see, the ICE reporting a Broken pipe error can only happen if
the gcc driver itself is invoked with SIGPIPE blocked. That is not the normal
case.
--
ian at airs dot com
--- Comment #14 from bernie at develer dot com 2006-08-28 00:59 ---
Please also backport to 4.1 (see #28863).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-08-28 01:38
---
(In reply to comment #14)
Please also backport to 4.1 (see #28863).
This never existed on 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-28 03:04
---
(In reply to comment #6)
An even smaller test case without a member function is:
Even smaller:
struct A
{
A(const A);
A operator=(const A);
};
void f(volatile A *a) { *a; }
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 03:08 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from bernie at develer dot com 2006-08-28 05:05 ---
(In reply to comment #15)
This never existed on 4.1.
gcc 4.1.1 from FC6 crashes with the testcase of bug 28863.
Maybe it's some redhat specific patch, but they follow
gcc's 4.0-branch quite closely these days:
Using
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-08-28 05:11
---
New results from the mainline:
optionssize
-Os 59
-Os -fno-ivopts 52
-Os -ftree-ch 58
-O2 64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-08-28 05:13
---
(In reply to comment #16)
(In reply to comment #15)
This never existed on 4.1.
gcc 4.1.1 from FC6 crashes with the testcase of bug 28863.
Maybe it's some redhat specific patch, but they follow
gcc's
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:14
---
Subject: Bug 28354
Author: jvdelisle
Date: Mon Aug 28 05:14:05 2006
New Revision: 116502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116502
Log:
2006-08-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:17
---
Subject: Bug 28354
Author: jvdelisle
Date: Mon Aug 28 05:17:09 2006
New Revision: 116503
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116503
Log:
2006-08-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:18
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 05:19 ---
Fixed in 4.2.0 20060827, was broken in 4.2.0 20060823.
Janis,
Could you run a regression hunt to figure out what fixed this?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-28 05:22 ---
(In reply to comment #7)
Note I am thinking revision 116409 fixed this but I am not too sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 05:25 ---
Janis,
Could you do a regression hunt on this bug?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 05:47 ---
HUH:
# D.34332_4 = PHI D.34332_139(7), D.34332_13(6);
# first$current$current$current_3 = PHI first$current$current$current_98(7),
first$current$current$current_11(6);
# first$current$current$current_282 = PHI
These two functions should produce the same asm but they don't:
int f(int t, int a, int b)
{
int c, d;
if (t)
{
c = a;
d = a;
}
else
{
c = b;
d = b;
}
return c+d;
}
int f1(int t, int a, int b)
{
int c;
c = t?a:b;
return c+c;
}
f1 is better
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
72 matches
Mail list logo
