--- 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
--- 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 #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
--
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
struct boo {
};
template class Base>
struct goo : Base {
};
int
main()
{
goo goo1;
--- 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., gc
--- 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 a
--- 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. Withou
--- 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
-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
--- 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
---
--- 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=19355&action=view)
A fix for the PR
The attached bootstraps and regtests. Will fix PR41117 at the same time.
Paul
--
pault at
--- 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=19354&action=view)
gcc44-pr42429.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- 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 #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]. Noth
--- 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
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|Unusual behavior of - |[4.5 Regression] -
|march=native option |ma
+++ 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
arithm
--- 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
--
--- 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 #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 #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 who
--- 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 ver
--- 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 #1)
--- 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
int f (char *s)
{
return strcmp (s, "");
}
If a warning like this is to be done by the F
--- 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 #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 #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 #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 #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: htt
--- 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 intrin
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
Product
--- 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
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.c
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 l1-cache-line-size=
--- 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 co
--- 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 #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 #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 accepts-
--- 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
Status|ASSIGNE
--- 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 __btowc_alia
--- 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 re
--- 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 i
--- 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 a/li
43 matches
Mail list logo
