derived from CP2K and discussed in PR 29975, the following is miscompiled with
the current 4.2 branch :
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/src cat test.f90
SUBROUTINE T(nsubcell,sab_max,subcells)
INTEGER, PARAMETER :: dp=KIND(0.0D0)
REAL(dp) :: sab_max(3),
--- Comment #127 from jv244 at cam dot ac dot uk 2007-06-28 06:08 ---
(In reply to comment #126)
As Andrew pointed out in PR 32521 the valgrind warning was fixed in 4.2.1
(prerelease). I've now built the 4.2_branch, and the warning is indeed gone,
but unfortunately the same
--- Comment #9 from bangerth at dealii dot org 2007-06-28 06:48 ---
Monologues don't help. Get your fingers out of the pockets and help us fix
bugs instead of complaining.
Richard has already acknowledged that you found
a bug two days after you filed it (and quite humorously). Your
--- Comment #4 from bangerth at dealii dot org 2007-06-28 06:52 ---
Apparently not a dup.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-28 07:00 ---
FX, thanks for your patch :)
As libgfortran is one of many, at least -static-libgomp would be nice to have
as well (others?). Reopening, so the request is not lost.
--
dfranke at gcc dot gnu dot org changed:
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-28 08:04 ---
(In reply to comment #4)
(In reply to comment #2)
This is related to PR 14771, most likely the parentheses are being ignored.
The parentheses are being ignored - in fact they disappear completely; I
presume that
--- Comment #1 from ubizjak at gmail dot com 2007-06-28 08:13 ---
Looks like problems in tree ifcvt pass. Before ifcvt, we have:
M.2_16 = (int4) D.1257_15;
if (M.2_16 1) goto L7; else goto L9;
L7:;
if (M.2_16 20) goto L10; else goto L9;
# M.2_64 = PHI M.2_16(6), 1(5);
L9:;
--- Comment #2 from ubizjak at gmail dot com 2007-06-28 08:14 ---
(In reply to comment #1)
This bug could be hidden in 4.3.0 as we use MIN_EXPR and MAX_EXPR here.
To clear the typo - we use MIN_EXPR and MAX_EXPR in 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #9 from ubizjak at gmail dot com 2007-06-28 08:36 ---
(In reply to comment #7)
This is what I get without -ftree-vectorize, with -ftree-vectorize (default
cost model off) and with -ftree-vectorize -fvect-cost-model respectively on an
AMD x86-64 (with trunk plus the patch
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #3 from schwab at suse dot de 2007-06-28 08:42 ---
A freestanding implementation is required to provide long long support.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #5 from irar at il dot ibm dot com 2007-06-28 09:02 ---
I think it is better to check that the statement is not NULL before calling
bsi_insert_on_edge_immediate. I am going to prepare a patch for this.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #10 from ubizjak at gmail dot com 2007-06-28 09:20 ---
Well, well - what can be found in _.146r.loop_unroll:
Loop 10 is simple:
simple exit 40 - 42
number of iterations: (const_int 8 [0x8])
upper bound: 8
;; Unable to prove that the loop rolls exactly once
;;
--- Comment #6 from pcarlini at suse dot de 2007-06-28 10:22 ---
Ok, I'm implementing the idea.
--
pcarlini at suse dot de changed:
What|Removed |Added
the following programm
---
#include iostream
struct A
{
A() : value(0) {}
int value;
};
templateclass T
struct B
{
static A a;
};
templateclass T A BT::a;
//template A Bint::a;
templateclass T
struct C
{
C() {
--- Comment #11 from ubizjak at gmail dot com 2007-06-28 11:39 ---
(In reply to comment #10)
;; Not peeling loop completely, rolls too much (8 iterations 8 [maximum
peelings])
This is meant that original + 8 unroll iterations 8. So, loop has 46 insns,
and 9 copies of loops is more
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-28 11:40
---
I suspect the vectorizer leaves us with too much dead statements that confuse
the complete unrollers size cost metric. Running dce after vectorization might
fix this.
--
--- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 ---
((float*) (((sbuf_header_t *) ((buf) == (buf)-buf[0]))-buf[0]))[i] = val;
is (after ommiting the casts)
*(1B + (i * 4)) = val;
Is that legal?
Vectorizer assumes that every data-ref has base_address. In the above
--- Comment #5 from eres at il dot ibm dot com 2007-06-28 11:55 ---
(Form off-line discussion with Richard Guenther)
For-
char str[2][16] = {thisis16charslo,thisis16charslo};
On ppc64 we will get -
static char C.0[2][16] = {thisis16charslo, thisis16charslo};
while on x86_64 -
--- Comment #13 from burnus at gcc dot gnu dot org 2007-06-28 12:03 ---
core2 AMD
0m45.215s 0m4.312s (no vectorize)
1m34.046s 0m4.668s -ftree-vectorize
0m45.447s 0m4.300s -ftree-vectorize -fvect-cost-model
i.e. -ftree-vectorize -fvect-cost-model is marginally faster than
Janus, how about submitting a patch for this bug including a testcase?
As Janus Weil found out:
http://gcc.gnu.org/ml/fortran/2007-06/msg00488.html
If a namelist in a procedure contained in a module procedure contains a private
item as element, a bogus error message is printed:
Error: PRIVATE
--- Comment #7 from rguenther at suse dot de 2007-06-28 12:20 ---
Subject: Re: [4.3 Regression] Segfault in
set_bb_for_stmt with -O -ftree-vectorize
On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote:
--- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41
--- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 ---
(In reply to comment #7)
I suppose rejecting NULL bases should work here?
Yes, only it's not NULL it's zero (0B).
We can reject it in the vectorizer or not create a dr for it...
Ira
--
--- Comment #9 from rguenther at suse dot de 2007-06-28 12:30 ---
Subject: Re: [4.3 Regression] Segfault in
set_bb_for_stmt with -O -ftree-vectorize
On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote:
--- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29
--- Comment #10 from irar at il dot ibm dot com 2007-06-28 12:38 ---
(In reply to comment #9)
I suppose all INTEGER_CST bases should be rejected.
Richard.
Right. The value actually doesn't matter since the constant part is split to
the init part in (tree-data-ref.c:656):
--- Comment #14 from ubizjak at gmail dot com 2007-06-28 12:59 ---
(In reply to comment #13)
core2 AMD
0m45.215s 0m4.312s (no vectorize)
Ehm, the first is full induct.f90 run on _nocona_, whereas AMD is the result of
running the attached test. The table with comparable results
--- Comment #8 from whaley at cs dot utsa dot edu 2007-06-28 14:18 ---
I've been doing further testing on the g5 (the only machine where I have local
and root access), and this problem does not occur with stock gcc 4.1.1 either.
Therefore, whatever problem is avoided by throwing
sample code:
#include stdio.h
int main()
{
char cp[2];
cp[0] = 'A';
cp[1] = 'B';
printf(%x %x\n,cp[0],cp[1]);
cp[0] ^= (cp[1]^=(cp[0]^=cp[1]));
printf(%x %x\n,cp[0],cp[1]);
return 0;
}
The complex byte swapping instruction is far fetched but seems legal.
It actually swaps bytes
When configured and made with
[descartes:gcc/objdirs/objdir-mainline] gcc-test% cat
../../mainline/build-and-check-gcc
#!/bin/tcsh
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../../mainline/configure
--build=powerpc64-apple-darwin8.9.0 --host=powerpc64-apple-darwin8.9.0
--- Comment #1 from schwab at suse dot de 2007-06-28 16:54 ---
You are modifying the same object twice between two sequence points.
*** This bug has been marked as a duplicate of 11751 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #77 from schwab at suse dot de 2007-06-28 16:54 ---
*** Bug 32536 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
All libgomp tests fail to link on IRIX 6:
Executing on host: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/xgcc
-B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/
/vol/gcc/src/gcc-dist/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-28 18:01 ---
This works for me in both 4.2.0 and the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from rob1weld at aol dot com 2007-06-28 18:32 ---
Why is it a bad idea to leave this flaw in GCC ?
Format String Bugs and Exploits
http://www.geocities.com/ravecoolr/fmt.doc
or if you like:
http://www.enderunix.org/docs/formatstr.txt
Allowing GCC to stay as-is and
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 ---
*** Bug 32529 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 ---
No, this is a dup as the bug there still has not been fixed for 4.1.x.
*** This bug has been marked as a duplicate of 28504 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-06-28 18:51
---
There is a -Wformat for a reason, use it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-28 19:04 ---
Subject: Bug 32417
Author: pinskia
Date: Thu Jun 28 19:03:49 2007
New Revision: 126082
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126082
Log:
2007-06-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-28 19:06
---
Again please read What I wrote about what the C99 standard requires. It
requires long long support for a freestanding compiler. So that is provided
with libgcc. If the Linux kernel team decides that they don't
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-28 19:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from e9fritte at etek dot chalmers dot se 2007-06-28 19:29
---
At that time I was probably using binutils 2.16 (Ubunty Edgy). It seems Feisty
still has that version. It's great if this has been resolved in 4.2, although
my workaround does its job for now. Thanks to
--- Comment #3 from tromey at gcc dot gnu dot org 2007-06-28 19:35 ---
Subject: Bug 30999
Author: tromey
Date: Thu Jun 28 19:35:25 2007
New Revision: 126090
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126090
Log:
2007-06-28 Jan Nijtmans [EMAIL PROTECTED]
PR
--- Comment #4 from eweddington at cso dot atmel dot com 2007-06-28 19:48
---
Closing bug as WORKSFORME.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2007-06-28 19:59 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
int f(void);
void acceptloop_th(int *t) {
int options = 0;
if (f()) options |= 0x1 0;
if (f()) options |= 0x1 1;
if (f()) options |= 0x1 2;
if (f()) options |= 0x1 3;
if (f()) options |= 0x1 4;
if (f()) options |= 0x1 5;
if (f()) options |= 0x1 6;
if
--- Comment #1 from falk at debian dot org 2007-06-28 20:15 ---
Created an attachment (id=13801)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13801action=view)
Original test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-28 20:25 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from paolo at gcc dot gnu dot org 2007-06-28 22:58 ---
Subject: Bug 32509
Author: paolo
Date: Thu Jun 28 22:58:32 2007
New Revision: 126096
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126096
Log:
2007-06-28 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #8 from paolo at gcc dot gnu dot org 2007-06-28 22:59 ---
Subject: Bug 32509
Author: paolo
Date: Thu Jun 28 22:59:00 2007
New Revision: 126097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126097
Log:
2007-06-28 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-28 23:01 ---
Created an attachment (id=13802)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13802action=view)
tests, early draft of a patch
Attached is some tests plus some minimal patch.
Using the patch most valid cases
--- Comment #9 from paolo at gcc dot gnu dot org 2007-06-28 23:02 ---
Subject: Bug 32509
Author: paolo
Date: Thu Jun 28 23:02:05 2007
New Revision: 126098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126098
Log:
2007-06-28 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #10 from pcarlini at suse dot de 2007-06-28 23:04 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 03:05 ---
Note we should also optimize:
int f(int a, int b)
{
int c = a+4;
int d = c*2;
int e = a*2;
int f = e+4;
return f+d;
}
into a*2 + 12; (or (a+6)*2 ) so that only one mutliplication is there.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-29 03:23 ---
Testing a patch for this right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-29 03:28
---
What was status on this? I think the patch was OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32483
I have a question about the behavior of gcc for powerpc.
I think the arguments -msdata and -msdata=default have same effect to gcc.
But gcc sent different argument to gas.
When -msdata is set, gcc sent -memb to gas.
When -msdata=default is set, gcc doesn't send -memb to gas.
I think `specs' has
58 matches
Mail list logo
