[Bug tree-optimization/31343] New: ICE in data-refs dependence testing
An attempt to divide by zero is made (causing ICE on the attached test
case) for evolution functions with zero step.
For the following evolution functions of pS[i_15].x and pS[i_15].y from the
attached test
(chrec_a = {{0, +, 1}_1, +, 0}_2)
(chrec_b = {{1, +, 1}_1, +, 0}_2)
the difference (-1) is calculated, and then the check whether the step
(0)divides the difference is performed in function
chrec_steps_divide_constant_p (tree-data-ref.c), causing ICE.
--
Summary: ICE in data-refs dependence testing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
[Bug tree-optimization/31343] ICE in data-refs dependence testing
--- Comment #1 from irar at il dot ibm dot com 2007-03-25 10:02 --- Created an attachment (id=13281) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13281&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
[Bug fortran/31196] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 10:29 --- Subject: Bug 31196 Author: tkoenig Date: Sun Mar 25 09:29:10 2007 New Revision: 123195 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123195 Log: 2007-03-25 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/31196 * intrinsics/reshape_generic.c (reshape_internal): Increment correct variable. 2007-03-25 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/31196 * gfortran.dg/reshape_transpose_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/reshape_transpose_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/reshape_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug target/31344] New: [4.3 regression] Bootstrap failure to compile decLibrary.c
My nightly bootstrap of mainline on i386-linux failed tonight, on revision 123192, with: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c: In function ?isinfd64?: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c:65: error: unrecognizable insn: (insn 11 10 12 3 /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c:62 (set (reg/f:SI 61) (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) (nil)) /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c:65: internal compiler error: in extract_insn, at recog.c:2119 The last revision known to compile OK on that particular setup was: 123178. I can reproduce it with the attached preprocessed source and the following command line: $ /home/fxcoudert/gfortran_nightbuild/ibin-20070325/./gcc/cc1 -fpreprocessed foo.i -mtune=i386 gnu_dev_major gnu_dev_minor gnu_dev_makedev __sigismember __sigaddset __sigdelset isinfd32 /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c: In function ?isinfd32?: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c:54: error: unrecognizable insn: (insn 10 9 11 3 (set (reg/f:SI 64) (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) (nil)) /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/decLibrary.c:54: internal compiler error: in extract_insn, at recog.c:2119 With -mtune=i[345]86, an ICE occurs, while for -mtune=i686 there is no problem. -- Summary: [4.3 regression] Bootstrap failure to compile decLibrary.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug fortran/30877] Extending intrinsic operators
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:01 --- Subject: Bug 30877 Author: fxcoudert Date: Sun Mar 25 10:01:23 2007 New Revision: 123196 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123196 Log: PR fortran/30877 * fortran/interface.c (check_operator_interface): Implement the standard checks on user operators extending intrinsic operators. * fortran/resolve.c (resolve_operator): If the ranks of operators don't match, don't error out but try the user-defined ones first. * gfortran.dg/operator_1.f90: New test. * gfortran.dg/operator_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/operator_1.f90 trunk/gcc/testsuite/gfortran.dg/operator_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877
[Bug fortran/30877] Extending intrinsic operators
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:02 --- Fixed, thanks Joost for the report! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-03-25 11:12 --- http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:19 --- (In reply to comment #1) > http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html Yes, thanks, I know. I followed in my patch (http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01605.html) the idea I already had at that time: if lstat() is not available, instead of not providing the library function for LTAT, we'll use stat(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Known to fail|4.1.3 4.2.0 4.3.0 |4.1.3 4.2.0 Known to work||4.3.0 Summary|wrong code generated with |[4.2/4.1 only] wrong code |RESHAPE/TRANSPOSE |generated with ||RESHAPE/TRANSPOSE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 21:21:25 |2007-03-25 10:47:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:49
---
$ cat nan.f90
real :: nan, x
x = 7.2
nan = 0.0
nan = nan / nan
print *, minval((/ nan, x /)), maxval((/ nan, x /))
print *, minval((/ nan /)), maxval((/ nan /))
print *, minloc((/ nan, x /)), maxloc((/ nan, x /))
print *, minloc((/ nan /)), maxloc((/ nan /))
end
$ gfortran nan.f90 && ./a.out
7.20 7.20
3.4028235E+38 -3.4028235E+38
1 1
1 1
While the results for {MIN,MAX}VAL, while not perfect, are not so bad (it's a
possible interpretation of the standard), the results for {MIN,MAX}LOC are very
annoying: it means that ARRAY(MAXLOC(ARRAY)) /= MAXVAL(ARRAY) !
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug tree-optimization/31345] New: [4.3 Regression] ICE in in set_value_range, at tree-vrp.c:269
Hi Ian,
Your fix for PR31034 worked for 18 out of 20 affected applications in Debian,
but there are 2 applications that still exhibit a related ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 qdbm-depot.c
qdbm-depot.c: In function 'dpsnaffle':
qdbm-depot.c:2: internal compiler error: in set_value_range, at tree-vrp.c:269
Please submit a full bug report,
with preprocessed source if appropriate.
Test case:
dpsnaffle (const char *kbuf)
{
int hash, thash, head[2], off;
{
int _DP_i;
(hash) = 19780211;
{
(hash) = (hash) + (kbuf)[_DP_i];
}
(hash) = ((hash) * 43321879) & 0x7FFF;
}
while (off != 0)
{
if (hash > thash) {}
else if (hash < thash)
{
off = head[2];
}
}
}
--
Summary: [4.3 Regression] ICE in in set_value_range, at tree-
vrp.c:269
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug tree-optimization/31345] [4.3 Regression] ICE in in set_value_range, at tree-vrp.c:269
--- Comment #1 from tbm at cyrius dot com 2007-03-25 12:28 --- Created an attachment (id=13282) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13282&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug target/30784] [4.3 regression] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)
--- Comment #9 from dorit at gcc dot gnu dot org 2007-03-25 13:08 --- Subject: Bug 30784 Author: dorit Date: Sun Mar 25 12:08:29 2007 New Revision: 123197 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123197 Log: PR tree-optimization/30784 * fold-const.c (fold_ternary): Handle CONSTRUCTOR in case BIT_FIELD_REF. Added: trunk/gcc/testsuite/gcc.dg/vect/pr30784.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
[Bug tree-optimization/31345] [4.3 Regression] ICE in in set_value_range, at tree-vrp.c:269
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-25 13:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 12:37:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug fortran/31346] New: wrong values for ubound and size of deferred shape arrays
size and ubound are lost when passing an array as argument of a procedure -- Summary: wrong values for ubound and size of deferred shape arrays Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-25 14:38 --- Created an attachment (id=13283) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13283&action=view) program showing the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-25 14:41 --- $ FC=gfortran; $FC -v; $FC -o test test.f; echo; ./test Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 size= 5 size= 25 ubound= 5 ubound= 5 5 size= 0 size= 0 ubound= 0 ubound= 2193121 0 FC=/usr/local/bin/gfortran; $FC -v; $FC -o test test.f; echo; ./test Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070316/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070316 (experimental) size= 5 size= 25 ubound= 5 ubound= 5 5 size=-250 size= 0 ubound= 0 ubound= 5222132 0 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added Known to fail||4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug c++/30303] [4.2/4.3 regression] ICE with invalid constructor definition
--- Comment #5 from dayas2003 at yahoo dot com 2007-03-25 15:07 --- I am unsing the following version: arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar I get the same error as said above. I am not sure whether to modify the Code [ there are many files; so painful solution :-( ] . Is there a way I can compile the above without touching the C-Files ? Which version of gcc should I use ? Can any one suggest me a solution. Thanks and Regards, Dayananda [EMAIL PROTECTED] +91 98452 59517 -- dayas2003 at yahoo dot com changed: What|Removed |Added CC||dayas2003 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
[Bug java/31325] gcj support for ARM EABI
--- Comment #12 from s_j_newbury at yahoo dot co dot uk 2007-03-25 16:52 --- (In reply to comment #11) > I have everything built except for libjava/exception.cc which fails as seen > below. > libjava/exception.cc needs special handling of the EABI unwind support as is done in the libsupc++ code. I'm going to be working on this shortly if no-one else does first, I have some other work to do first. I don't yet know if the EABI unwind ABI supports everything needed for java exceptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug tree-optimization/31343] ICE in data-refs dependence testing
--- Comment #2 from pthaugen at us dot ibm dot com 2007-03-25 18:38 --- I hit the same ICE building the 191.fma3d benchmark from cpu2000 when compiling lsold.f90 with -O2 -ftree-loop-linear. -- pthaugen at us dot ibm dot com changed: What|Removed |Added CC||pthaugen at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
[Bug tree-optimization/31345] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:269
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-25 18:41 --- I think this is a regression also on the 4.2 branch now since the set of patches that caused this is also there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 18:58 --- Note, I think decLibrary.c changed but does not cause this not to be an user visible regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c/31347] New: Internal compiler error: unrecognizable insn
This happes trying to compile gettetxt-0.16 with -O3 -mthreads -msse2 -mmmx ...
Note that it compiles just fine without all the
'-march=pentium4 -msse -msse2 -mmmx -O3 -mfpmath=sse -mthreads -Wall -v
-save-temps' options ...
Here is the output
/bin/sh ../libtool --tag=CC --mode=compile i786-pc-mingw32-gcc
-DLOCALEDIR=\"/mingw/share/locale\" -DBISON_LOCALEDIR=\"\"
-DLOCALE_ALIAS_PATH=\"/mingw/share/locale\" -DUSEJEXE=1
-DGETTEXTJEXEDIR=\"/mingw/lib/gettext\"
-DGETTEXTJAR=\"/mingw/share/gettext/gettext.jar\" -DLIBDIR=\"/mingw/lib\"
-DGETTEXTDATADIR=\"/mingw/share/gettext\"
-DPROJECTSDIR=\"/mingw/share/gettext/projects\" -DHAVE_CONFIG_H -I. -I.. -I.
-I. -I.. -I.. -I../libgrep -I../libuniname -I../gnulib-lib -I../gnulib-lib
-I../intl -I../../gettext-runtime/intl -I/mingw/include -march=pentium4 -msse
-msse2 -mmmx -O3 -mfpmath=sse -mthreads -Wall -v -save-temps -c -o
msgl-check.lo msgl-check.c
i786-pc-mingw32-gcc -DLOCALEDIR=\"/mingw/share/locale\" -DBISON_LOCALEDIR=\"\"
-DLOCALE_ALIAS_PATH=\"/mingw/share/locale\" -DUSEJEXE=1
-DGETTEXTJEXEDIR=\"/mingw/lib/gettext\"
-DGETTEXTJAR=\"/mingw/share/gettext/gettext.jar\" -DLIBDIR=\"/mingw/lib\"
-DGETTEXTDATADIR=\"/mingw/share/gettext\"
-DPROJECTSDIR=\"/mingw/share/gettext/projects\" -DHAVE_CONFIG_H -I. -I.. -I.
-I. -I.. -I.. -I../libgrep -I../libuniname -I../gnulib-lib -I../gnulib-lib
-I../intl -I../../gettext-runtime/intl -I/mingw/include -march=pentium4 -msse
-msse2 -mmmx -O3 -mfpmath=sse -mthreads -Wall -v -save-temps -c msgl-check.c
-DDLL_EXPORT -DPIC -o .libs/msgl-check.o
Using built-in specs.
Target: i786-pc-mingw32
Configured with: ../gcc-4.1.1/configure --disable-win32-registry
--enable-threads --enable-tls --prefix=/mingw --with-arch=pentium4
i786-pc-mingw32 : (reconfigured) ../gcc-4.1.1/configure
--disable-win32-registry --enable-threads --enable-tls --prefix=/mingw
--with-arch=pentium4 --enable-languages=c,c++ i786-pc-mingw32
Thread model: win32
gcc version 4.1.1
d:/local/msys/1.0/mingw/bin/../libexec/gcc/i786-pc-mingw32/4.1.1/cc1.exe -E
-quiet -v -I. -I.. -I. -I. -I.. -I.. -I../libgrep -I../libuniname
-I../gnulib-lib -I../gnulib-lib -I../intl -I../../gettext-runtime/intl
-ID:/Local/msys/1.0/mingw/include -iprefix
d:\local\msys\1.0\mingw\bin\../lib/gcc/i786-pc-mingw32/4.1.1/ -D_MT
-DLOCALEDIR="D:/Local/msys/1.0/mingw/share/locale" -DBISON_LOCALEDIR=""
-DLOCALE_ALIAS_PATH="D:/Local/msys/1.0/mingw/share/locale" -DUSEJEXE=1
-DGETTEXTJEXEDIR="D:/Local/msys/1.0/mingw/lib/gettext"
-DGETTEXTJAR="D:/Local/msys/1.0/mingw/share/gettext/gettext.jar"
-DLIBDIR="D:/Local/msys/1.0/mingw/lib"
-DGETTEXTDATADIR="D:/Local/msys/1.0/mingw/share/gettext"
-DPROJECTSDIR="D:/Local/msys/1.0/mingw/share/gettext/projects" -DHAVE_CONFIG_H
-DDLL_EXPORT -DPIC msgl-check.c -march=pentium4 -msse -msse2 -mmmx -mfpmath=sse
-mthreads -Wall -O3 -fpch-preprocess -o msgl-check.i
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory
"D:/Local/msys/1.0/mingw/i786-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
.
..
.
.
..
..
../libgrep
../libuniname
../gnulib-lib
../gnulib-lib
../intl
../../gettext-runtime/intl
D:/Local/msys/1.0/mingw/include
d:/local/msys/1.0/mingw/bin/../lib/gcc/i786-pc-mingw32/4.1.1/include
D:/Local/msys/1.0/mingw/include
D:/Local/msys/1.0/mingw/lib/gcc/i786-pc-mingw32/4.1.1/include
End of search list.
d:/local/msys/1.0/mingw/bin/../libexec/gcc/i786-pc-mingw32/4.1.1/cc1.exe
-fpreprocessed msgl-check.i -quiet -dumpbase msgl-check.c -march=pentium4 -msse
-msse2 -mmmx -mfpmath=sse -mthreads -auxbase-strip .libs/msgl-check.o -O3 -Wall
-version -o msgl-check.s
GNU C version 4.1.1 (i786-pc-mingw32)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131006
Compiler executable checksum: fdfb34fc179dab6a0e7af749688cf25a
msgl-check.c: In function 'plural_help':
msgl-check.c:195: error: unrecognizable insn:
(insn 38 36 39 4 (set (reg:SI 76)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.plural_table") ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
msgl-check.c:195: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: Internal compiler error: unrecognizable insn
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terminatorul at gmail dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31347
[Bug c/31348] New: Error in compilation
Version exacta: gcc version 4.1.0 System type: Windows Vista Manufacturer: Dell Model: Inspiron I6400 Rating: Windows Experience Index: Unrated Processor: Genuine Intel(R) CPU T2060 @ 1.60GHz 1.60 GHz Memory(Ram): 1022 Mb System type: 32-bit Operating System Gcc configured/built: Environment Variables : path (things)\;C:\DJGPP\bin;C:\DJGPP\programasC Command line that triggers the bug: gcc hola.c -o hola.exe Compiler output: gcc.exe: Internal error: (null) (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed file: cc1 -E -quiet -v -iprefix c:/djgpp/bin/../lib/gcc/dgjpp/4.10/ -remap -imacros c :/djgpp/bin/../lib/gcc/djgpp/4.10/djgpp.ver hola.c -mtune=pentium -fpch-preprocess -o hola.i -- Summary: Error in compilation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gabo143 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31348
[Bug target/31347] Internal compiler error: unrecognizable insn
--- Comment #1 from terminatorul at gmail dot com 2007-03-25 19:17 --- Created an attachment (id=13284) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13284&action=view) C source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31347
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #2 from hjl at lucon dot org 2007-03-25 19:18 --- Where is "the attached preprocessed source"? -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug target/31347] Internal compiler error: unrecognizable insn
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 --- *** This bug has been marked as a duplicate of 29826 *** *** This bug has been marked as a duplicate of 29826 *** -- 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=31347
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 --- *** Bug 31347 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||terminatorul at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug c/31348] Error in compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:22 --- Vista is not support right now IIRC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Summary|Error in compilation|Error in compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31348
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:23 --- Created an attachment (id=13285) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13285&action=view) Preprocessed source file triggering the ICE Here's the preprocessed source, sorry for forgetting it in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c/31348] Error in compilation
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 --- *** This bug has been marked as a duplicate of 30972 *** -- 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=31348
[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 --- *** Bug 31348 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gabo143 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt (for vista)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 18:23:55 date|| Summary|Call to _access has invalid |Call to _access has invalid |parameter when linked with |parameter when linked with |msvcrt |msvcrt (for vista) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:38
---
Reduced testcase:
$ cat a.c
typedef struct
{
unsigned char bits;
} decNumber;
typedef struct
{
unsigned char bytes[1];
} decimal32;
decNumber *__decimal32ToNumber (const decimal32 *, decNumber *);
void __host_to_ieee_32 (_Decimal32, decimal32 *);
extern int isinfd32 (_Decimal32);
int
isinfd32 (_Decimal32 arg)
{
decNumber dn;
decimal32 d32;
__host_to_ieee_32 (arg, &d32);
__decimal32ToNumber (&d32, &dn);
}
$ ./cc1 a.i -mtune=i386
isinfd32
/home/fxcoudert/foo.i: In function ?isinfd32?:
/home/fxcoudert/foo.i:22: error: unrecognizable insn:
(insn 10 9 11 3 (set (reg/f:SI 60)
(pre_dec:SI (reg/f:SI 7 sp))) -1 (nil)
(nil))
/home/fxcoudert/foo.i:22: internal compiler error: in extract_insn, at
recog.c:2119
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug middle-end/30784] [4.3 regression] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-25 19:40 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|target |middle-end Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-25 20:34 --- Thomas, the testcase fails the execution test on i386-darwin at all optimization levels in an up-to-date tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #13 from tobi at gcc dot gnu dot org 2007-03-25 20:51 --- I have a patch which does eveything, except detecting branches to END DOs. I can't seem to figure out how to do this in a sensible way without introducing a replacement quadratic bottleneck :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-03-25 20:55 --- (In reply to comment #5) > Thomas, the testcase fails the execution test on i386-darwin at all > optimization levels in an up-to-date tree. *sigh* Can you maybe investigate the following: - print line1 and line 2 in the testcase (to see what goes wrong) Also, what's the output of program main integer, dimension(2,2) :: data, result data(1,1) = 1 data(2,1) = 2 data(1,2) = 3 data(2,2) = 4 result = reshape(transpose(data),shape(data)) write (*,'(4I4)') result END program main (to check whether reshape_4 is doing the right thing here). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug c++/30500] pragma GCC system_header vs templates
--- Comment #2 from pcarlini at suse dot de 2007-03-25 21:01 --- I'm looking into this: apparently the problem is just (or mostly) that at the beginning of instantiate_decl we are not copying DECL_IN_SYSTEM_HEADER (d) into in_system_header: doing it fixes the test here (and avoids the warnings in 30463 and 30464) without regressions. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 20:01:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-25 21:56 --- I do not believe the patch will help with the original missed optimization because the backend never sees a direct assignment from the CONSTRUCTOR -- it already is placed in memory. The example in comment #2 is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-03-25 22:04 --- I'll give this a shot. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-06 12:12:21 |2007-03-25 21:04:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 22:18 --- Subject: Bug 31297 Author: tkoenig Date: Sun Mar 25 21:17:51 2007 New Revision: 123200 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123200 Log: 2007-03-25 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/31297 * gfortran.dg/backspace_5.f: Initialize variable(s). * gfortran.dg/backspace_6.f: Likewise. * gfortran.dg/char_bounds_check_fail_1: Likewise. * gfortran.dg/direct_io_2.f90: Likewise. * gfortran.dg/write_back.f: Likewise. * gfortran.dg/write_rewind_2.f: Likewise. * gfortran.dg/write_rewind_1.f: Likewise. * gfortran.dg/write_rewind_2.f: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/backspace_5.f trunk/gcc/testsuite/gfortran.dg/backspace_6.f trunk/gcc/testsuite/gfortran.dg/char_bounds_check_fail_1.f90 trunk/gcc/testsuite/gfortran.dg/direct_io_2.f90 trunk/gcc/testsuite/gfortran.dg/write_back.f trunk/gcc/testsuite/gfortran.dg/write_rewind_1.f trunk/gcc/testsuite/gfortran.dg/write_rewind_2.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-25 22:55 ---
(In reply to comment #4)
> I do not believe the patch will help with the original missed optimization
> because the backend never sees a direct assignment from the CONSTRUCTOR -- it
> already is placed in memory. The example in comment #2 is different.
Did I miss something because for the original example the back-end does see the
CONSTRUCTOR in rs6000_expand_vector_init as a parallel with the mode of V4SI.
The expansion of vect_cst_.30 + {4, 4, 4, 4} calls rs6000_expand_vector_init
with vals being:
(parallel:V4SI ([ (const_int 4),(const_int 4),(const_int 4),(const_int 4) ]) )
So when we call easy_vector_constant with vals, we always get false as it is
not a const_vector. My patch changes it so we call easy_vector_constant with a
const_vector as we already proved in the loop above it is made up of constant
elements as n_var is zero.
For the orginal testcase, the assembly now looks like (on powerpc-darwin):
_main1:
mfspr r0,256
stw r0,-4(r1)
oris r0,r0,0xc00c
mtspr 256,r0
lis r2,ha16(LC0)
la r2,lo16(LC0)(r2)
vspltisw v0,4
lvx v1,0,r2
li r2,23
mtctr r2
vor v12,v0,v0
mr r0,r3
vor v13,v1,v1
vadduwm v0,v1,v0
L2:
vadduwm v13,v13,v0
vadduwm v0,v0,v12
bdnz L2
vsldoi v0,v13,v13,8
addi r2,r1,-20
lwz r12,-4(r1)
vadduwm v0,v0,v13
vsldoi v1,v0,v0,12
vadduwm v1,v1,v0
stvewx v1,0,r2
lwz r3,-20(r1)
add r3,r3,r0
mtspr 256,r12
blr
.const
.align 4
LC0:
.long 0
.long 1
.long 2
.long 3
Notice how we have vspltisw outside the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-25 23:05 ---
Now the patch does not solve the following testcase:
int main1 (int X)
{
int s = X;
int i;
for (i = 0; i < 96*16; i+=16)
s += i;
return s;
}
For this one to be fixed, we need to define an insn which does vec_duplicate as
an insn_and_split instead of expanding it up in the rs6000_expand_vector_init.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-25 23:36 --- Something like: (define_insn_and_split "altivec_dup" [(set (match_operand:V 0 "register_operand" "v") (vec_duplicate: (match_operand: 0 "r"))) (clobber (match_operand:V 3 "memory_operand" "=Z"))] "TARGET_ALTIVEC" "#" "&& reload_completed" Which then will be generated from rs6000_expand_vector_init. I can write this if you want, it is just I cannot test this until Monday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug other/31349] New: gcc -v --help returns no options for C, C++
To quote from the output of gcc -v --help on gcc (GCC) 4.3.0 20070323 (experimental): -- The following options are specific to the language Ada: -gnat Specify options to GNAT The following options are specific to the language C: No options with the desired characteristics were found The following options are specific to the language C++: No options with the desired characteristics were found -- As can be seen by comparing this to the output from 4.2, something seems to be missing. (What's missing from Ada is all the options shared with C, specifically.) Similarly, on the Fortran output, while the Fortran-specific options are present, the ones shared with C and C++ aren't listed. 4.3 currently gives -- The following options are specific to the language Fortran: -J Put MODULE files in 'directory' -Waliasing Warn about possible aliasing of dummy arguments [...] -- However, 4.2 gives: -- The Fortran front end recognizes the following options: -I, -Wall, -Wconversion, -fopenmp, -fpreprocessed, -fshort-enums -J Put MODULE files in 'directory' -Waliasing Warn about possible aliasing of dummy arguments [...] -- The same problem with the missing shared options in the output occurs for other languages as well. -- Summary: gcc -v --help returns no options for C, C++ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug other/31350] New: gcc -v --help puts some output on std. out, and some on std. error.
gcc -v --help is inconsistent about where it places its output. If I try to redirect the output to a file (which is rather a reasonable thing to do, given how long it is!), some of it still gets printed to the console via standard error: > bin-4.2/bin/gcc -v --help > /dev/null Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion : (reconfigured) ../svn-source-4.2/configure --verbose --prefix=/home/brooks/bin-4.2 --enable-languages=c,c++,fortran --no-create --no-recursion Thread model: posix gcc version 4.2.0 20070305 (prerelease) /home/brooks/bin-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -mtune=generic -auxbase help-dummy -version --help -o /tmp/cccRY7zh.s as -V -Qy --help -o /tmp/ccQzyIru.o /tmp/cccRY7zh.s GNU assembler version 2.15 (i386-linux) using BFD version 2.15 /home/brooks/bin-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 --help /usr/lib/crt1.o /usr/lib/crti.o /home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o -L/home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0 -L/home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/../../.. /tmp/ccQzyIru.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/brooks/bin-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/crtend.o /usr/lib/crtn.o FWIW, this error only seems to be present with the gcc -v --help output; the regular gcc --help output all goes into the file, as expected. -- Summary: gcc -v --help puts some output on std. out, and some on std. error. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org 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=31350
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 23:48 --- This was caused by: 2007-02-12 Nick Clifton <[EMAIL PROTECTED]> * doc/invoke.texi (Overall Options): Document --help=. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 22:48:12 date|| Summary|gcc -v --help returns no|[4.3 Regression] gcc -v -- |options for C, C++ |help returns no options for ||C, C++ Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug other/31351] New: gcc -v --help has poor documentation for some shared Ada/C options
When an option is shared between multiple front ends, the output of gcc -v --help uses the documentation string from the first front end for which it is listed. Ada is listed before C, and thus all of the shared Ada/C options use the Ada documentation, rather than the C documentation. Unfortunately, the Ada lang.opt file doesn't have good documentation for some of these: --- The Ada front end recognizes the following options: -I This switch lacks documentation -Wall This switch lacks documentation -Wlong-long Do not warn about using "long long" when -pedantic -Wmissing-format-attribute Warn about functions which might be candidates for format attributes -Wmissing-prototypesWarn about global functions without prototypes -Wold-style-definition Warn if an old-style parameter definition is used -Wstrict-prototypes Warn about unprototyped function declarations -Wvariadic-macros Do not warn about using variadic macros when -pedantic -Wwrite-strings In C++, nonzero means warn about deprecated conversion from string literals to `char *'. In C, similar warning, except that the conversion is of course not deprecated by the ISO C standard. -fRTS= This switch lacks documentation -gnat Specify options to GNAT -gnatO This switch lacks documentation -nostdinc Do not search standard system include directories (those specified with -isystem will still be used) -nostdlib This switch lacks documentation --- My personal opinion is that this would really be best fixed by listing C and C++ first in the --help output, since they're much more commonly used. However, a workaround would be copying the C documentation to the Ada lang.opt file. -- Summary: gcc -v --help has poor documentation for some shared Ada/C options Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31351
[Bug other/31352] New: gcc -v --help doesn't notice when front-ends documentation differs for same option
When an option is present in multiple front ends, the gcc -v --help output assumes that the documentation is the same in all of the front ends for which the option is present, and only reports the documentation string for the first front end for which it appears. For example, in 4.2, the Ada output has --- -Wall This switch lacks documentation --- and then, in the C output, we have --- -I, -Wall, -Wlong-long, -Wmissing-format-attribute, -Wmissing-prototypes, --- rather than giving the documentation string for -Wall that's present in c.opt. Currently, I _think_ this is only affecting the Ada options that lack documentation (and are thus bug #31351), but it seems unfortunate for the future as well, since some options may have different interpretations in different langauges. -- Summary: gcc -v --help doesn't notice when front-ends documentation differs for same option Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31352
[Bug fortran/31294] Endless loop when compiling a cyclic code
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:07 --- *** This bug has been marked as a duplicate of 31306 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31294
[Bug fortran/31306] ICE with implicit character variables
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 00:07 --- *** Bug 31294 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31306
[Bug fortran/31266] Spurious(?) warning about character truncation
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:13 --- It probably shouldn't say "rhs" in the error message, either. It looks like we don't look through the references correctly when determining the length of the rhs, though I can't see exactly where this goes wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug other/31353] New: gcc --help=target gives a linker error.
Consider the following output: > ~/bin-trunk/bin/gcc --help=target The following options are target specific: -m128bit-long-doublesizeof(long double) is 16 -m32Generate 32bit i386 code [...] -muclibcUse uClibc instead of GNU libc /usr/lib/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' collect2: ld returned 1 exit status This happens with any --help= option. It looks like the "--help=" option isn't turning off the parts of the compiler that do compilation, and so it's still trying to link an empty program. -- Summary: gcc --help=target gives a linker error. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org 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=31353
[Bug middle-end/31354] New: NaN should only fail comparisons for equality
I'm guessing at middle-end here, maybe it is target...
I don't think it is correct for NaNs to fail any comparison.
They should only fail comparisons which include equality.
$ cat compare.c
#include
int main()
{
float nan, x;
nan = 0.0;
nan = nan / nan;
x = 3.2;
printf("%f\n", nan);
printf("%d %d %d %d\n", x > nan, x < nan, x >= nan, x <= nan);
return 0;
}
$ gcc compare.c && ./a.out
nan
0 0 0 0
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/ig25/gcc/trunk/configure --prefix=/home/ig25
--enable-maintainer-mode --enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20070317 (experimental)
--
Summary: NaN should only fail comparisons for equality
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31354
[Bug other/31355] New: --help= option isn't documented.
The documentation in invoke.texi for the --help= option only lists the "optimizers", "warnings", "target", and "params" values that the option can take. However, it can also take a language name as a value, and this isn't documented. -- Summary: --help= option isn't documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug middle-end/31354] NaN should only fail comparisons for equality
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:27 --- NaN's are unordered so they will compare false for ordered operators. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31354
[Bug other/31356] New: gcc --help= option has problems in the output header line.
Consider the following output: > ~/bin-trunk/bin/gcc --help=fortran The following options are supported by, amoung others, the language : -I This switch lacks documentation [...] The language name seems to be missing from the first line. (Also, "amoung" is an obvious typo.) -- Summary: gcc --help= option has problems in the output header line. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug driver/31353] gcc --help=target gives a linker error.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:33 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |NEW Component|other |driver Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 23:33:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug driver/31355] --help= option isn't documented.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |NEW Component|other |driver Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2007-03-25 23:34:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug other/31357] New: --help and --help= options cannot be combined.
As documented, using multiple --help= options in one command line produces an output that concatenates the output from the various --help= options. However, using both --help and --help= gives only the --help output, regardless of the order in which they are specified. -- Summary: --help and --help= options cannot be combined. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31357
[Bug fortran/31207] advance="no" and tabs
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-26 01:00 --- Turns out this is not a duplicate of 31199. However its is closel related. I wll work this one as well. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31207] advance="no" and tabs
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2007-03-17 15:36:58 |2007-03-26 00:00:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #5 from hjl at lucon dot org 2007-03-26 01:18 --- It also happens with -Os: bash-3.1$ /export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/ -m32 -S -o bar.s bar.i -Os bar.i: In function isinfd32: bar.i:22: error: unrecognizable insn: (insn 11 10 12 3 (set (reg/f:SI 61) (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) (nil)) bar.i:22: internal compiler error: in extract_insn, at recog.c:2119 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug driver/31353] gcc --help=target gives a linker error.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-25 23:33:06 |2007-03-26 00:21:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
[Bug other/31356] gcc --help= option has problems in the output header line.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-26 00:33:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-26 01:44 --- Richard, are you able to confirm this bug? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #6 from hjl at lucon dot org 2007-03-26 01:55 --- Jan, it may be related to your code: http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00263.html Any idea? -- hjl at lucon dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-26 01:59 --- This works on the trunk at least on powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF
For:
int *f(int *a, int b, int c)
{
int i;
a --;
*a = 1;
for (i = 0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
[Bug rtl-optimization/14737] Purge political statement from -ffast-math docs
--- Comment #5 from bangerth at dealii dot org 2007-03-26 03:13 --- Manuel, thanks for (re-)submitting the patch today. I don't have the infrastructure to test patches any more these days, but I appreciate that someone takes up the issue again. I think the text duplication is not the biggest issue. It could be tackled later on, but I think it is more important to fix the issue. Thanks W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #7 from hjl at lucon dot org 2007-03-26 03:15 --- It looks like expr.c and i386.c don't agree how to generate push instuction. i386.c has gen_push and expr.c has emit_single_push_insn. If emit_single_push_insn is called, it will generate invalid patten: (insn 10 9 11 3 (set (reg/f:SI 64) (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) (nil)) from emit_single_push_insn in expr.c 3519 if (GET_MODE_SIZE (mode) == rounded_size) 3520dest_addr = gen_rtx_fmt_e (STACK_PUSH_CODE, Pmode, stack_pointer_rtx); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #8 from hjl at lucon dot org 2007-03-26 04:04 --- The invalid insn is added via #0 add_insn (insn=0x2aafc690) at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:3411 #1 0x004fb88d in emit_insn (x=0x2aafc690) at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:4336 #2 0x0051f3f8 in emit_move_insn_1 (x=0x2acecd80, y=0x2acfb080) at /export/gnu/src/gcc/gcc/gcc/expr.c:3260 #3 0x0051f725 in emit_move_insn (x=0x2acecd80, y=0x2acfb080) at /export/gnu/src/gcc/gcc/gcc/expr.c:3351 #4 0x00507baf in force_reg (mode=SImode, x=0x2acfb080) at /export/gnu/src/gcc/gcc/gcc/explow.c:680 #5 0x00507695 in memory_address (mode=SImode, x=0x2acfb080) at /export/gnu/src/gcc/gcc/gcc/explow.c:485 #6 0x004f7491 in change_address_1 (memref=0x2acecd60, mode=SImode, addr=0x2acfb080, validate=1) at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:1811 #7 0x004f7add in adjust_address_1 (memref=0x2acecd60, mode=SImode, offset=0, validate=1, adjust=1) at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:1895 #8 0x0051e778 in emit_move_change_mode (new_mode=SImode, old_mode=SDmode, x=0x2acecd60, force=1 '\001') at /export/gnu/src/gcc/gcc/gcc/expr.c:2882 #9 0x0051e830 in emit_move_via_integer (mode=SDmode, x=0x2acecd60, y=0x2acecb40, force=1 '\001') ---Type to continue, or q to quit--- at /export/gnu/src/gcc/gcc/gcc/expr.c:2921 #10 0x0051f45f in emit_move_insn_1 (x=0x2acecd60, y=0x2acecb40) at /export/gnu/src/gcc/gcc/gcc/expr.c:3268 #11 0x0051f725 in emit_move_insn (x=0x2acecd60, y=0x2acecb40) at /export/gnu/src/gcc/gcc/gcc/expr.c:3351 #12 0x0051fecc in emit_single_push_insn (mode=SDmode, x=0x2acecb40, type=0x2ab16c00) at /export/gnu/src/gcc/gcc/gcc/expr.c:3582 #13 0x00520757 in emit_push_insn (x=0x2acecb40, mode=SDmode, type=0x2ab16c00, size=0x0, align=32, partial=0, reg=0x0, extra=0, args_addr=0x0, args_so_far=0x2aafb400, reg_parm_stack_space=0, alignment_pad=0x2aafb400) at /export/gnu/src/gcc/gcc/gcc/expr.c:3852 #14 0x004a3c1c in store_one_arg (arg=0x7fff5d787aa8, argblock=0x0, flags=0, variable_size=0, reg_parm_stack_space=0) at /export/gnu/src/gcc/gcc/gcc/calls.c:4239 #15 0x0049f94c in expand_call (exp=0x2acebb40, target=0x0, ignore=1) at /export/gnu/src/gcc/gcc/gcc/calls.c:2652 #16 0x0052a40c in expand_expr_real_1 (exp=0x2acebb40, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /export/gnu/src/gcc/gcc/gcc/expr.c:7785 #17 0x00527414 in expand_expr_real (exp=0x2acebb40, target=0x2aafb400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /export/gnu/src/gcc/gcc/gcc/expr.c:6785 We didn't see this problem before is because decimal float wasn't enabled by default on x86 until revision 123185. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug fortran/31199] write with "t1" + nonadvancing transfer format gives wrong output
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:23 --- Subject: Bug 31199 Author: jvdelisle Date: Mon Mar 26 04:23:15 2007 New Revision: 123205 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123205 Log: 2007-03-25 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31199 *io/io.h: Add saved_pos to gfc_unit structure. *io/open.c (new_unit): Initialize saved_pos. *io/transfer.c (data_transfer_init): Set max_pos to value in saved_pos. (next_record_w): Fix whitespace. (finalze_transfer): Calculate max_pos for ADVANCE="no" and save it for later use. If not ADVANCE="no" set saved_pos to zero. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug middle-end/22156] [4.0/4.1/4.2/4.3 Regression] bit-field copying regressed
--- Comment #11 from patchapp at dberlin dot org 2007-03-26 04:40 --- Subject: Bug number PR 22156 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01625.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug rtl-optimization/14737] Purge political statement from -ffast-math docs
--- Comment #6 from patchapp at dberlin dot org 2007-03-26 04:41 --- Subject: Bug number PR 14737 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01649.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #14 from patchapp at dberlin dot org 2007-03-26 04:41 --- Subject: Bug number PR 18937 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01650.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/31199] write with "t1" + nonadvancing transfer format gives wrong output
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:41 --- Subject: Bug 31199 Author: jvdelisle Date: Mon Mar 26 04:41:29 2007 New Revision: 123207 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123207 Log: 2007-03-25 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31199 * gfortran.dg/fmt_t_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_t_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug other/31359] New: 4.2 branch still generates abort for function casting
The eventual consensus of the ml thread "gcc 4.2 more strict check for "function called through a non-compatibletype" [1]: Mark Mitchell wrote: > > Ian Lance Taylor wrote: > > >> >> I realized that I am still not stating my position very clearly. I >> >> don't think we should make any extra effort to make this code work: >> >> after all, the code is undefined. I just think 1) we should not >> >> insert a trap; 2) we should not ICE. > > > > I agree. If the inlining thing is indeed a problem (and I can see how > > it could be, even though you could not immediately reproduce it), then > > we should mark the call as uninlinable. Disabling an optimization in > > the face of such a cast seems more user-friendly than inserting a trap. > > Since we know the code is undefined, we're not pessimizing correct > > code, so this is not a case where to support old code we'd be holding > > back performance for valid code. > > > > I also agree with Gaby that we should document this as an extension. If > > we go to the work of putting it back in, we should ensure that it > > continues to work for the foreseeable future. Part of that is writing > > down what we've decided. Was there ever any action on this? AFAICS consensus was that the trap would be removed and this behaviour be documented as an extension. There was a bit more discussion of how exactly the documentation would be worded and the thread petered out. Fast forwarding to today the abort is still present and the 4.2 branch (4.2.0-pre20070317 (rev. 123016)) is still unable to build a working openssl (0.9.8e). I apologize for bringing this up so late in the release cycle. I only found this discussion this weekend while searching for some solution to our openssl issue, which i believe is the only blocker we have left as far as being gcc-4.2 ready. [1] http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html -- Summary: 4.2 branch still generates abort for function casting Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-26 05:43 --- I agree with Joseph that STRIP_SIGN_NOPS should not be removing changes in precision that may change the value and that, indeed, mode is probably being used as an inaccurate proxy for precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-03-26 05:58 --- Created an attachment (id=13286) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13286&action=view) the working case The problem arise when the subroutine is not defined in a contains statement in the main program. I haven't seen anything in the Fortran 2003 standard forcing the subroutines to be in the contains statement. But even if it is the case, the compiler should report an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:01 --- Can you show the exact code from openssl which has the problem, there might be better ways of writting the code instead of what they are doing right now. This code is still undefined and I don't think we really should change the behavior of GCC to be a behavior of code which is undefined. Before we would crash on some of the undefined behavior but now we don't and we warn more places where the undefined behavior happens so that is even better thing. At least we don't sliently cause the undefined behavior to be crash (which is actually valid for the C standard). I rather see openssl fix their code than GCC change the behavior, it is not like they were depending on defined behavior and GCC causes defined behavior to become undefined. Also if we say this was an "undocumented extension", I think that is wrong as there is no such thing as an undocumented extension, just it worked because GCC did not fail before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug rtl-optimization/31360] New: [4.3 Regression] rtl loop invariant is broken
Testcase:
void f(int *a)
{
int i;
for (i = 0;i<100;i++)
a[i] = 0;
}
---cut-
we get:
_f:
li r0,0
li r2,4
stw r0,0(r3)
li r0,99
mtctr r0
L2:
li r0,0
stwx r0,r2,r3
addi r2,r2,4
bdnz L2
blr
the "li r0,0" should be moved out of the loop but is not.
--
Summary: [4.3 Regression] rtl loop invariant is broken
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:48 ---
I get:
Set in insn 47 is invariant (0), cost 4, depends on
Where insn 47 is the load constant:
(insn 47 46 48 3 (set (reg:SI 156)
(const_int 0 [0x0])) 328 {*movsi_internal1} (nil)
(nil))
If I change the constant to DEADBEEF, it removes it from the loop. I should
check if this is true on the 4.2 branch too because I think it is.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2007-03-26 07:00 --- Here is a new patch. I need someone to test on SPEC. It is very simple. Index: transfer.c === *** transfer.c (revision 123205) --- transfer.c (working copy) *** next_record_r (st_parameter_dt *dtp) *** 2228,2234 break; } ! if (dtp->u.p.current_unit->flags.access == ACCESS_SEQUENTIAL) test_endfile (dtp->u.p.current_unit); } --- 2228,2235 break; } ! if (dtp->u.p.current_unit->flags.access == ACCESS_SEQUENTIAL ! && !dtp->u.p.namelist_mode) test_endfile (dtp->u.p.current_unit); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #4 from daney at gcc dot gnu dot org 2007-03-26 07:07 --- Subject: Bug 31228 Author: daney Date: Mon Mar 26 07:07:13 2007 New Revision: 123208 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123208 Log: PR libgcj/31228 * configure.ac: Add checks for getrlimit and sys/resource.h. * include/posix.h (_Jv_platform_close_on_exec): Remove. * include/config.h.in: Regenerate. * configure: Regenerate. * gnu/java/nio/channels/natFileChannelPosix.cc (open): Remove call to _Jv_platform_close_on_exec; * gnu/java/net/natPlainSocketImplPosix.cc (create): Likewise. (accept): Likewise. * gnu/java/net/natPlainDatagramSocketImplPosix.cc (create):Likewise. * java/lang/natPosixProcess.cc: Include sys/resource.h. (nativeSpawn): Close all file descriptors. Don't set FD_CLOEXEC on pipes. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/configure branches/gcc-4_2-branch/libjava/configure.ac branches/gcc-4_2-branch/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc branches/gcc-4_2-branch/libjava/gnu/java/net/natPlainSocketImplPosix.cc branches/gcc-4_2-branch/libjava/gnu/java/nio/channels/natFileChannelPosix.cc branches/gcc-4_2-branch/libjava/include/config.h.in branches/gcc-4_2-branch/libjava/include/posix.h branches/gcc-4_2-branch/libjava/java/lang/natPosixProcess.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #5 from daney at gcc dot gnu dot org 2007-03-26 07:13 --- Committed to the 4.2 branch as well. -- daney at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-26 07:19 --- (In reply to comment #3) > I haven't seen anything in the Fortran 2003 standard forcing the subroutines > to > be in the contains statement. In this case the interface is said to be implicit and the standard does not require the programme to do the right thing. Use an INTERFACE, as below, or put the subroutine in a module. In either case the interface will be made explicit. > But even if it is the case, the compiler should report an error. This is not a requirement of the standard but is a long standing regression, relative to g77. Confirmed and marked as "diagnostic" Nous t'en remercions Cordialement Paul program test interface subroutine test1(x,y) real(kind=8), dimension(:) :: x real(kind=8), dimension(:,:) :: y end subroutine end interface real(kind=8), dimension(5) :: test_array real(kind=8), dimension(5,5) :: test_array2 real(kind=8) :: taille write(6,*) 'size=', size(test_array) write(6,*) 'size=', size(test_array2) write(6,*) 'ubound=', ubound(test_array) write(6,*) 'ubound=', ubound(test_array2) call test1(test_array, test_array2) end program > -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail|4.1.2 |4.3.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-03-26 07:19:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
