[Bug lto/41902] Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared)
--- 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|Removed |Added CC||davek at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41902
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- 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 CC||leonleon77 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/42446] gcc crash (internal compiler error) during the build of C++ code
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42446
[Bug c++/42446] New: gcc crash (internal compiler error) during the build of C++ code
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;
return 0;
}
Start of command-line which causes the crash:
gcc main.cc
Start of gcc-output as it crashes:
main.cc: In function 'int main()':
main.cc:13: internal compiler error: in dependent_type_p, at
cc1plus/../../../../contrib/gcc/cp/pt.c:12777
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Start of gcc --version output:
%gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Start of uname -a output:
%uname -a
FreeBSD localhost 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC
2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
--
Summary: gcc crash (internal compiler error) during the build of
C++ code
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leonleon77 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42446
[Bug c/42440] optimization bug with btwowc(EOF) in wchar.h
--- 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 -std=gnu99 -O2 conftest.i. Without that > option, > indeed, the resulting executables runs ok. In fact if you are using -std=gnu99 then the behavior here is correct to the C99 standard's "extern inline" behavior. the function is exported no matter what for extern inline in C99, this is why gnu_inline exists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
[Bug c/42440] optimization bug with btwowc(EOF) in wchar.h
--- 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 and without -fgnu89-inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
[Bug c/42440] optimization bug with btwowc(EOF) in wchar.h
--- 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. Without that option, indeed, the resulting executables runs ok. Thanks, Karl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
--- 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
[Bug driver/42445] New: -march=native isn't saved in COLLECT_GCC_OPTIONS
On Linux/ia32, I got [...@gnu-29 gcc]$ ./xgcc -B./ -S -march=native x.i -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: i686-pc-linux-gnu Configured with: ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-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-size=2048 -mtune=nocona -quiet -dumpbase x.i -auxbase x -version -o x.s GNU C (GCC) version 4.5.0 20091220 (experimental) [trunk revision 155368] (i686-pc-linux-gnu) compiled by GNU C version 4.5.0 20091220 (experimental) [trunk revision 155368], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20091220 (experimental) [trunk revision 155368] (i686-pc-linux-gnu) compiled by GNU C version 4.5.0 20091220 (experimental) [trunk revision 155368], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 02fd4faf11d3fb405ccd44e93f31b44f COMPILER_PATH=./ LIBRARY_PATH=./:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B./' '-S' '-v' [...@gnu-29 gcc]$ ./xgcc -B./ -S -march=i686 x.i -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: i686-pc-linux-gnu Configured with: ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-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' '-march=i686' '-v' ./cc1 -fpreprocessed x.i -quiet -dumpbase x.i -march=i686 -auxbase x -version -o x.s GNU C (GCC) version 4.5.0 20091220 (experimental) [trunk revision 155368] (i686-pc-linux-gnu) compiled by GNU C version 4.5.0 20091220 (experimental) [trunk revision 155368], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20091220 (experimental) [trunk revision 155368] (i686-pc-linux-gnu) compiled by GNU C version 4.5.0 20091220 (experimental) [trunk revision 155368], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 02fd4faf11d3fb405ccd44e93f31b44f COMPILER_PATH=./ LIBRARY_PATH=./:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B./' '-S' '-march=i686' '-v' [...@gnu-29 gcc]$ -- Summary: -march=native isn't saved in COLLECT_GCC_OPTIONS Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42445
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
--- 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 CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug fortran/41113] spurious _gfortran_internal_pack
--- 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 gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- 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: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug fortran/42422] Error in Fortran list directed input
--- 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
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- 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]. Nothing looks at MEM's MODE when a specific MEM_SIZE is given. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
--- 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
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
-- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|Unusual behavior of - |[4.5 Regression] - |march=native option |march=native doesn't apply ||to multiple files Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug driver/42444] New: "-march=i386 -march=native -mfpmath=sse" problem
+++ 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 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=64 --param l2-cache-size=512 -mtune=pentium4 -quiet -dumpbase 1.c -march=i386 -mfpmath=sse -auxbase 1 -o /tmp/ccGVyoDg.s -march=native is moved to the beginning, so -march=i386, though given before it, overrides it. This can be confusing because it is not how other -march=... options do behave. -- Summary: "-march=i386 -march=native -mfpmath=sse" problem Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu BugsThisDependsOn: 42442 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42444
[Bug driver/42442] Unusual behavior of -march=native option
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-20 20:35:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug fortran/42422] Error in Fortran list directed input
--- 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. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42422
[Bug fortran/42422] Error in Fortran list directed input
--- 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 CC||tkoenig at gcc dot gnu dot ||org Known to fail||4.3.2 Known to work||4.3.4 4.4.1 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42422
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- 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 whole.f90 $ -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org OtherBugsDependingO||40011 nThis|| Severity|normal |enhancement Known to fail|4.3.0 4.2.0 |4.3.0 4.2.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- 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 verification :) -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug fortran/42443] open ignores status statement
--- 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)
> 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 intrinsic
> GET_ENVIRONMENT_VARIABLE to get the value of HOME:
>
> CHARACTER(len=255) :: homedir
> CALL GET_ENVIRONMENT_VARIABLE("HOME", homedir)
> OPEN(unit=101, file=TRIM(homedir) // '/Moti.txt', status='REPLACE')
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42443
[Bug c++/35652] [4.3/4.4/4.5 Regression] offset warning should be given in the front-end
--- 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 FE, it would need to be only queued
in the IL and emitted only if it survived at least some initial DCE. Perhaps
in a form of an artificial __builtin_warning, or something similar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug fortran/41113] spurious _gfortran_internal_pack
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-20 18:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/42443] open ignores status statement
--- 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 Severity|blocker |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42443
[Bug c++/35652] [4.3/4.4/4.5 Regression] offset warning should be given in the front-end
--- 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
[Bug c++/42058] [4.3/4.4 Regression] Trouble with invalid array initialization
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug libmudflap/32276] [4.3/4.4/4.5 Regression]: libmudflap.c++/pass41-frag.cxx
--- 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: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00752.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2007-07-13 00:55:55 |2009-12-20 16:12:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug fortran/42443] 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 intrinsic
GET_ENVIRONMENT_VARIABLE to get the value of HOME:
CHARACTER(len=255) :: homedir
CALL GET_ENVIRONMENT_VARIABLE("HOME", homedir)
OPEN(unit=101, file=TRIM(homedir) // '/Moti.txt', status='REPLACE')
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42443
[Bug fortran/42443] New: open ignores status statement
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: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: motiz at 012 dot net dot il http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42443
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 32 and 64 bit modes with -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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.cgi?id=41082
[Bug driver/42442] New: Unusual behavior of -march=native option
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=64 --param l2-cache-size=512 -mtune=pentium4 -quiet -dumpbase 1.c -mfpmath=sse -auxbase 1 -o /tmp/ccwiYM9g.s /usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1 -quiet 2.c -quiet -dumpbase 2.c -mfpmath=sse -auxbase 2 -o /tmp/ccwiYM9g.s This is a regression. 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 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=64 --param l2-cache-size=512 -mtune=pentium4 -quiet -dumpbase 1.c -march=i386 -mfpmath=sse -auxbase 1 -o /tmp/ccGVyoDg.s -march=native is moved to the beginning, so -march=i386, though given before it, overrides it. This can be confusing because it is not how other -march=... options do behave. -- Summary: Unusual behavior of -march=native option Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 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 in > vect_can_force_dr_alignment_p(), and it seems that the only target specific > query there is comparison with MAX_STACK_ALIGNMENT. That sounds odd. If we don't make use of the extra alignment how should it affect generated code or even correctness? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 in vect_can_force_dr_alignment_p(), and it seems that the only target specific query there is comparison with MAX_STACK_ALIGNMENT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 (reduce > 6) tmp = sum(reduce) print *, tmp end program already fail for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- 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-invalid - certainly invalid as not documented as an extension). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug c/42440] optimization bug with btwowc(EOF) in wchar.h
--- 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_alias (int __c) __asm ("btowc");
extern __inline int
__attribute__ ((__nothrow__,gnu_inline)) btowc (int __c)
{
return (__builtin_constant_p (__c)
&& __c >= '\0'
&& __c <= '\x7f' ? __c : __btowc_alias (__c));
}
int main()
{
btowc (-1);
return 0;
}
In reply to comment #2 - this is a standard technique used in glibc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 reduction itself. > Could you please verify that by printing the reduction result? I have changed the code to: program where_2 integer temp(10), reduce(10), tmp(10) temp = 10 reduce(1:3) = -1 reduce(4:6) = 0 reduce(7:8) = 5 reduce(9:10) = 10 tmp = 0 WHERE (reduce < 0) temp = 100 ELSE WHERE (reduce .EQ. 0) temp = 200 + temp ELSE WHERE WHERE (reduce > 6) tmp = sum(reduce) temp = 300 + temp + tmp END WHERE print *, temp print *, tmp if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) & call abort end program And with r155350 I get [karma] f90/bug% gfc -O3 where_2_db.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 337 310 310 0 0 0 0 0 0 0 27 0 0 Abort [karma] f90/bug% gfc -m64 -O3 where_2_db.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 337 337 0 0 0 0 0 0 0 0 27 27 [karma] f90/bug% while with r151300 I get: [karma] f90/bug% gfcp -O3 where_2_db.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 337 337 0 0 0 0 0 0 0 0 27 27 [karma] f90/bug% gfcp -m64 -O3 where_2_db.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 310 310 0 0 0 0 0 0 0 0 0 0 Abort [karma] f90/bug% So sum(reduce) gives the right result, but apparently it is not stored in the right place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- 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 itself. Could you please verify that by printing the reduction result? Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- 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/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 07aa4d9..531f6ec 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -42,13 +42,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If
/* For mingw, we don't identify files by their inode number, but by a
64-bit identifier created from a BY_HANDLE_FILE_INFORMATION. */
-#if defined(__MINGW32__) && !HAVE_WORKING_STAT
+#ifdef __MINGW32__
#define WIN32_LEAN_AND_MEAN
#include
#define lseek _lseeki64
+#define fstat _fstati64
+#define stat _stati64
+typedef struct _stati64 gfstat_t
+#ifndef HAVE_WORKING_STAT
static uint64_t
id_from_handle (HANDLE hFile)
{
@@ -91,6 +95,9 @@ id_from_fd (const int fd)
}
#endif
+#else
+typedef struct stat gfstat_t
+#endif
#ifndef PATH_MAX
#define PATH_MAX 1024
@@ -781,7 +788,7 @@ open_internal (char *base, int length, gfc_offset offset)
static stream *
fd_to_stream (int fd, int prot)
{
- struct stat statbuf;
+ gfstat_t statbuf;
unix_stream *s;
s = get_mem (sizeof (unix_stream));
@@ -1220,9 +1227,9 @@ int
compare_file_filename (gfc_unit *u, const char *name, int len)
{
char path[PATH_MAX + 1];
- struct stat st1;
+ gfstat_t st1;
#ifdef HAVE_WORKING_STAT
- struct stat st2;
+ gfstat_t st2;
#else
# ifdef __MINGW32__
uint64_t id1, id2;
@@ -1261,7 +1268,7 @@ compare_file_filename (gfc_unit *u, const char *name, int
#ifdef HAVE_WORKING_STAT
-# define FIND_FILE0_DECL struct stat *st
+# define FIND_FILE0_DECL gfstat_t *st
# define FIND_FILE0_ARGS st
#else
# define FIND_FILE0_DECL uint64_t id, const char *file, gfc_charlen_type
file_l
@@ -1318,7 +1325,7 @@ gfc_unit *
find_file (const char *file, gfc_charlen_type file_len)
{
char path[PATH_MAX + 1];
- struct stat st[2];
+ gfstat_t st[2];
gfc_unit *u;
#if defined(__MINGW32__) && !HAVE_WORKING_STAT
uint64_t id = 0ULL;
@@ -1455,7 +1462,7 @@ int
file_exists (const char *file, gfc_charlen_type file_len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (unpack_filename (path, file, file_len))
return 0;
@@ -1478,7 +1485,7 @@ const char *
inquire_sequential (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1502,7 +1509,7 @@ const char *
inquire_direct (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1526,7 +1533,7 @@ const char *
inquire_formatted (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
This is completely untested.
And, as a general observation, if mingw is ever going to be a tier-1 target for
gfortran, we need one or more maintainers who use and care about gfortran on
windows. So far all the maintainers are, to the best of my knowledge, Linux or
FreeBSD users, and any mingw support is, at best, an afterthought. Same goes
for OS X, FWIW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
