--- Comment #6 from jb at gcc dot gnu dot org 2009-12-20 10:23 ---
As such the patch seems ok, however I'd prefer to avoid cluttering up the logic
with ifdefs, and secondly, we should stick to one kind of stat struct
everywhere for consistency's sake. E.g. something like
diff --git
--- Comment #23 from irar at il dot ibm dot com 2009-12-20 12:18 ---
The code that now gets vectorized is the summation of array 'reduce':
sum(reduce). It looks like the problem is with adding the reduction result to
the correct index of 'temp' (scalar code), and not with the reduction
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-20 12:46 ---
The code that now gets vectorized is the summation of array 'reduce':
sum(reduce). It looks like the problem is with adding the reduction result to
the correct index of 'temp' (scalar code), and not with the
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-20 13:11 ---
Works for me. The preprocessed source is certainly not what was compiled
(I assume the linkage specification of btowc was actually different).
Working testcase, robustened against -std=c99:
extern int
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-12-20 13:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-20 13:15 ---
Ugh. The kernel should stick to the usual pattern of arrays with negative
sizes instead of bitfields ...
I wouldn't mind if this would be closed as invalid (even though technically
a regression to a former
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-12-20 13:33
---
Works on i?86-linux, the reduction is vectorized as well. Does
program where_2
integer reduce(10), tmp(10)
tmp = 0
reduce(1:3) = -1
reduce(4:6) = 0
reduce(7:8) = 5
reduce(9:10) = 10
WHERE
--- Comment #26 from irar at il dot ibm dot com 2009-12-20 13:46 ---
I think the problem is in alignment. We force alignment of temp.6 and temp.20 -
the arrays of relevant comaprison results - even though we don't vectorize
their loop. The decision whether we can force alignment is made
--- Comment #27 from rguenther at suse dot de 2009-12-20 13:48 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
On Sun, 20 Dec 2009, irar at il dot ibm dot com wrote:
--- Comment #26 from irar at il dot ibm dot
GCC 4.5.0 20091217. When I run `gcc -c -march=native -mfpmath=sse 1.c 2.c', it
gives a warning: `2.c:1:0: warning: SSE instruction set disabled, using 387
arithmetics'.
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1 -quiet 1.c -march=pentium4
--param l1-cache-size=8 --param
--- Comment #28 from irar at il dot ibm dot com 2009-12-20 13:59 ---
Hm, I don't know, but this is my best guess - we change something in the code
that goes wrong...
We also force alignment of reduce, but the reduction computation looks ok.
--
--- Comment #29 from dominiq at lps dot ens dot fr 2009-12-20 14:19 ---
Works on i?86-linux, the reduction is vectorized as well.
Yes I know, this is specific to ppc-darwin.
Does
...
WHERE (reduce 6) tmp = sum(reduce)
...
already fail for you?
No, this test works fine in
Trying to create new file, using open statement with status='REPLACE' causing a
runtime error, file not found.
the specific syntex:
open(unit=101, file='~/Moti.txt', status='REPLACE')
got same result with status='NEW'
Moti
--
Summary: open ignores status statement
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-20 15:07 ---
Try with a proper path, i.e. without the '~'. Replacement of special characters
or wildcards is done on the shell level, not within the application.
To place a file in the home directory of the user, use the
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-20 16:12 ---
Reconfirming on all active branches for x86_64-unknown-linux-gnu:
gcc-4.5: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01759.html
gcc-4.4: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01486.html
gcc-4.3:
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-20 16:19
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #33 from jason at gcc dot gnu dot org 2009-12-20 18:09 ---
Why was the patch reverted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
--- Comment #2 from kargl at gcc dot gnu dot org 2009-12-20 18:31 ---
Change Severity to 'normal'. Fortran bugs are never 'Blocker'.
Close as INVALID. See comment #2 for the reason.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2009-12-20 18:47 ---
Confirmed
I will post a somewhat simpler patch, once it has regtested if it does :-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from jakub at gcc dot gnu dot org 2009-12-20 18:50 ---
It was warning too much, even about if (0) code, so it broke a lot of valid
code with -Werror, including stuff like:
#include string.h
int f (char *s)
{
return strcmp (s, );
}
If a warning like this is to be done
--- Comment #3 from motiz at 012 dot net dot il 2009-12-20 19:25 ---
You are right.
However, it was working on Redhat with gcc 4.3.?.
Now I am working on ubuntu 9.10 with gcc-4.4.1 and it did not work, unless I
used the explicit path.
Thank you very much
Moti
(In reply to comment
--- Comment #13 from davek at gcc dot gnu dot org 2009-12-20 19:59 ---
(In reply to comment #12)
(In reply to comment #11)
(In reply to comment #10)
Should be fixed in SVN now. Rainer, please verify when you get a chance.
Seems to work now!
Rainer
That counts as
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-12-20 20:10 ---
We fail to catch the invalid code
$ cat whole.f90
program main
real, dimension(2) :: a
call foo(a)
end program main
subroutine foo(a)
real, dimension(:) :: a
end subroutine foo
$ gfortran -fwhole-file -O3
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-12-20 20:17 ---
I can confirm this works on all supported versions.
Should we add a test case, then close this bug?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2009-12-20 20:33 ---
(In reply to comment #3)
I can confirm this works on all supported versions.
Should we add a test case, then close this bug?
IMHO. Yes.
A new testcase is pre-approved provided it passes a
regression test. :-)
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-20 20:35 ---
There are 2 separate bugs. Please open a new one for
-march=i386 -march=native -mfpmath=sse.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
+++ This bug was initially created as a clone of Bug #42442 +++
There is also other undocumented feature (I see that bug 42365 has been
resolved as invalid), `gcc -c -march=i386 -march=native -mfpmath=sse 1.c'
produces a warning: `1.c:1:0: warning: SSE instruction set disabled, using 387
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|Unusual behavior of - |[4.5 Regression] -
|march=native option
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-20 20:40 ---
(In reply to comment #1)
There are 2 separate bugs. Please open a new one for
-march=i386 -march=native -mfpmath=sse.
I opened PR 42444 for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-20 20:49 ---
I believe the bug is in [7 %sfp+-140 S1 A8], IMHO it should have been S4,
because otherwise the MEM attrs say it is 1 byte at %sfp+-140, which
nonoverlapping_memrefs_p says can't overlap with [7 %sfp+-137 S1 A8].
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-12-20 20:57
---
Thomas, let me know if you want me to do the test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42422
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-20 21:17 ---
Created an attachment (id=19354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19354action=view)
gcc44-pr42429.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #6 from pault at gcc dot gnu dot org 2009-12-20 21:58 ---
Created an attachment (id=19355)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19355action=view)
A fix for the PR
The attached bootstraps and regtests. Will fix PR41117 at the same time.
Paul
--
pault at
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-20 21:58 ---
It is caused by revision 148271:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00251.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-in-ld -with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20091220 (experimental) [trunk revision 155368] (GCC)
COLLECT_GCC_OPTIONS='-B./' '-S' '-v'
./cc1 -fpreprocessed x.i -march=nocona -mcx16 -msahf --param l1-cache-size=16
--param l1-cache-line-size=64 --param l2-cache
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-20 22:18 ---
This may be related to PR 42445.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
--- Comment #4 from karl at freefriends dot org 2009-12-20 23:09 ---
Works for me. The preprocessed source is certainly not what was compiled
Yes, it was. But I apologize, the invocation needs to include -std=gnu99 to
observe the problem, e.g., gcc -std=gnu99 -O2 conftest.i.
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-21 00:23 ---
If so, then you are using too old glibc headers with -std=gnu99, without
fixincludes and without -fgnu89-inline. Only headers of glibc later than
mid-2007 are prepared for -std=gnu99 with GCC 4.3 without fixincludes
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-21 00:32 ---
(In reply to comment #4)
Works for me. The preprocessed source is certainly not what was compiled
Yes, it was. But I apologize, the invocation needs to include -std=gnu99 to
observe the problem, e.g., gcc
Whatever the gcc should do, I don't think it should crash in the following case
(I shall try to re-build the latest 4.4.2 series to reproduce it there as well,
if I'll find the time):
Start of code:
template typename N, N M
struct boo {
};
template typename N, N P, template typename X, X M
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-21 05:04 ---
*** This bug has been marked as a duplicate of 37142 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-12-21 05:04
---
*** Bug 42446 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-21 05:11 ---
This problem will be resolved in the next few days when I release an official
cygwin distro package for libelf, which will have this issue fixed. HTH :)
--
davek at gcc dot gnu dot org changed:
What
43 matches
Mail list logo
