[Bug fortran/37787] right-left hand side overlap not recognized with EQUIVALENCEd array assignment
--- Comment #3 from pault at gcc dot gnu dot org 2008-10-19 07:51 --- Fixed on trunk and 4.3 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37787
[Bug fortran/37787] right-left hand side overlap not recognized with EQUIVALENCEd array assignment
--- Comment #4 from pault at gcc dot gnu dot org 2008-10-19 07:52 --- Subject: Bug 37787 Author: pault Date: Sun Oct 19 07:50:35 2008 New Revision: 141219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141219 Log: 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37787 * dependency.c (gfc_are_equivalenced_arrays): Look in symbol namespace rather than current namespace, if it is available. 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37787 * gfortran.dg/module_equivalence_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_equivalence_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37787
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #22 from burnus at gcc dot gnu dot org 2008-10-19 09:44 --- (In reply to comment #19) Warning: CHARACTER expression at (1) is being truncated (222/200) Tobias, you are right - the string is too short - 250 characters should do, however, and I get the same error. How did you provoke the warning (I certainly do not get it by default) ... Well, actually I saw it when I compiled the program with NAG f95 (Initialisation expression for L truncated) which shows this message by default. gfortran shows it with -Wcharacter-truncation or with -Wall (which I used). [Contrary to NAG f95, gfortran shows the warning not only for initialization expressions.] (In reply to comment #21) Toon and Tobias: Please try this attached patch. Looks OK. The only thing I need to determine now is if there is a legacy behaviour we may want to deal with Sunf95 and ifort seem to read -- without quotes -- all alphanumerical characters plus e.g. § until the next space/comma (and they treat %'$ special- ignore, end of string/namelist or as error). With NAG f95, g95, openf95, pathf95 and pgf95 one gets always an error message without quotes. With gfortran-4.3 str=test / does not work but str=test,/ does. I think the patch by itself is OK but doing the same as ifort and sunf95 would be also OK. Interesting that this did not come up as issue before. Seemingly no one uses write(...,namelist) with characters (as almost all compiler get this wrong) and seemingly reading a list of characters is also not widely done. @@ -1453,7 +1453,7 @@ namelist_write (st_parameter_dt *dtp) break; default: - dtp-u.p.nml_delim = '\0'; + dtp-u.p.nml_delim = ''; wouldn't it be easier/faster to simply remove the whole switch and use simply dtp-u.p.nml_delim = ''; without special cases for the current delim status? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug c/37870] New: ICE in extract_bit_field_1
Reproducing this is easy.
cat ICE.sample.c 'EOF'
typedef unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
unsigned xxx(long double arg)
{
struct
{
char dummy[8];
unsigned yyy:7;
} copy;
memcpy(copy, arg, sizeof(copy));
return copy.yyy;
}
EOF
invoking 'gcc -c -O1 sample.c' then emits
/home/bernard/ICE.sample.c: In function xxx:
/home/bernard/ICE.sample.c:8: internal compiler error: in extract_bit_field_1,
at expmed.c:1271
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is quite sensitive! Small changes make the ICE
go away. These include
using -O0
re-sizing the array member dummy[] in the struct
Replacing the memcpy() with an assignment via a
cast pointer:
give the struct a tag (e.g., struct fimbulwinter)
copy = *((struct fimbulwinter *)arg)
renaming memcpy() at both occurrences to by-pass the built-in
The last is suggestive, no?
This is NOT a duplicate of bug 37269, though the ICE is reported from
the same function. I get the same behaviour after applying Andrew
Pinski's patch for that bug. In fact, I found this bug in an echt
4.3.1 bootstrap build, applied AP's patch, still had it, then used
that compiler to bootstrap a 4.3.2 build, also with AP's patch.
Even using xgcc/cc1 from the stage 1 boostrap build of 4.3.2
showed the bug (there was nothing extra interesting in the
diagnostics produced).
'configure' was invoked with
'../gcc-4.3.2/configure' '--prefix=/usr' '--libexecdir=/usr/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-libada'
'--enable-libssp' '--disable-werror' '--with-mpfr=/usr' '--with-gmp=/usr'
'--with-datarootdir=/usr/share' '--with-docdir=/usr/share/gcc-4.3.2/doc'
'--with-pdfdir=/usr/share/gcc-4.3.2/doc'
'--with-htmldir=/usr/share/gcc-4.3.2/doc/html' '--disable-coverage'
'--enable-nls' '--enable-__cxa_atexit' '--enable-decimal-float'
'--disable-fixed-point' '--enable-threads=posix' '--enable-clocale=gnu'
'--enable-shared' '--disable-intermodule'
'--enable-languages=ada,c++,fortran,java,objc,obj-c++,treelang,c'
'--with-local-prefix=/usr' '--with-gnu-ld' '--with-demangler-in-ld'
'--with-gnu-as' '--with-system-libunwind' '--with-system-zlib'
'--enable-bootstrap'
All those single quotes derive from my build scripts, which quote-and-
escape everything in sight. The actual CPU is an Athlon64 X2 5600+
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37870
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #7 from burnus at gcc dot gnu dot org 2008-10-19 12:01 --- *** Bug 37827 has been marked as a duplicate of this bug. *** -- burnus 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=37839
[Bug fortran/37827] Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-19 12:01 --- *** This bug has been marked as a duplicate of 37839 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37827
[Bug libgcj/37871] New: testsuite/libjava.mauve is out of date / doesn't work with current mauve
Running /scratch/packages/gcc/svn/classpath-098-merge-branch/libjava/testsuite/libjava.mauve/mauve.exp ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a pax tar archive... gnutar checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for Windows and DOS and OS/2 style pathnames... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... none configure: creating ./config.status config.status: creating Makefile config.status: creating gnu/testlet/config.java config.status: executing depfiles commands make[2]: Entering directory `/scratch/packages/gcc/svn/build-cpbranch/i686-linux-gnu/libjava/testsuite/mauve-build' make[2]: *** No rule to make target `classes.stamp'. make[2]: Leaving directory `/scratch/packages/gcc/svn/build-cpbranch/i686-linux-gnu/libjava/testsuite/mauve-build' FAIL: Mauve build -- Summary: testsuite/libjava.mauve is out of date / doesn't work with current mauve Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37871
[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-19 12:40 ---
Confirmed.
We try to expand
return (unsigned int) VIEW_CONVERT_EXPRstruct
{
char dummy[8];
unnamed-unsigned:7 yyy;
}(arg).yyy;
which is SRAed from the gimplified memcpy
copy = VIEW_CONVERT_EXPRstruct
{
char dummy[8];
unnamed-unsigned:7 yyy;
}(arg);
to
bb 2:
copy$yyy_5 = 0;
copy$dummy$7_6 = VIEW_CONVERT_EXPRstruct
{
char dummy[8];
unnamed-unsigned:7 yyy;
}(arg_4(D)).dummy[7];
...
SR.9_14 = VIEW_CONVERT_EXPRstruct
{
char dummy[8];
unnamed-unsigned:7 yyy;
}(arg_4(D)).yyy;
copy$yyy_15 = SR.9_14;
SR.10_16 = copy$yyy_15;
D.1204_1 = SR.10_16;
D.1203_2 = (unsigned int) D.1204_1;
return D.1203_2;
It seems extract_bitfield_1 doesn't have a fallback path going through memory:
1261 /* Make sure we are playing with integral modes. Pun with subregs
1262 if we aren't. */
1263 {
1264enum machine_mode imode = int_mode_for_mode (GET_MODE (op0));
1265if (imode != GET_MODE (op0))
(gdb) l
1266 {
1267if (MEM_P (op0))
1268 op0 = adjust_address (op0, imode, 0);
1269else
1270 {
1271gcc_assert (imode != BLKmode);
obviously fails on i?86 with
(gdb) call debug_rtx (op0)
(reg/v:XF 59 [ arg ])
simply not going down this path and relying on the fallback seems to work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.3.2 4.4.0
Known to work||4.2.4
Last reconfirmed|-00-00 00:00:00 |2008-10-19 12:40:45
date||
Summary|ICE in extract_bit_field_1 |[4.3/4.4 Regression] ICE in
||extract_bit_field_1
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-19 12:40:45 |2008-10-19 12:50:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #8 from pault at gcc dot gnu dot org 2008-10-19 12:52 --- Subject: Bug 37723 Author: pault Date: Sun Oct 19 12:51:06 2008 New Revision: 141221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141221 Log: 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37723 * dependency.c (gfc_dep_resolver ): If we find equal array element references, go on to the next reference. 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37723 * gfortran.dg/dependency_22.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #9 from pault at gcc dot gnu dot org 2008-10-19 12:58 --- Subject: Bug 37723 Author: pault Date: Sun Oct 19 12:56:41 2008 New Revision: 141222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141222 Log: 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37723 * dependency.c (gfc_dep_resolver ): If we find equal array element references, go on to the next reference. 2008-10-19 Paul Thomas [EMAIL PROTECTED] PR fortran/37723 * gfortran.dg/dependency_22.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/dependency_22.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug c/30260] Enumeration types and enumeration constants erroneously given unsigned types
--- Comment #8 from manu at gcc dot gnu dot org 2008-10-19 13:53 --- Subject: Bug 30260 Author: manu Date: Sun Oct 19 13:52:10 2008 New Revision: 141224 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141224 Log: 2008-10-19 Manuel López-Ibáñez [EMAIL PROTECTED] PR c/30260 * c-decl.c (finish_enum): Convert non-integer enumerators to enum type. (build_enumerator): Convert enumerators that fit in integer to integer type. testsuite/ * gcc.dg/pr30260.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr30260.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
[Bug c/37872] New: ICE in extract_bit_field_1
Reproducing this is easy.
cat ICE.sample.c 'EOF'
typedef unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
unsigned xxx(long double arg)
{
struct
{
char dummy[8];
unsigned yyy:7;
} copy;
memcpy(copy, arg, sizeof(copy));
return copy.yyy;
}
EOF
invoking 'gcc -c -O1 sample.c' then emits
/home/bernard/ICE.sample.c: In function xxx:
/home/bernard/ICE.sample.c:8: internal compiler error: in extract_bit_field_1,
at expmed.c:1271
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is quite sensitive! Small changes make the ICE
go away. These include
using -O0
re-sizing the array member dummy[] in the struct
Replacing the memcpy() with an assignment via a
cast pointer:
give the struct a tag (e.g., struct fimbulwinter)
copy = *((struct fimbulwinter *)arg)
renaming memcpy() at both occurrences to by-pass the built-in
The last is suggestive, no?
This is NOT a duplicate of bug 37269, though the ICE is reported from
the same function. I get the same behaviour after applying Andrew
Pinski's patch for that bug. In fact, I found this bug in an echt
4.3.1 bootstrap build, applied AP's patch, still had it, then used
that compiler to bootstrap a 4.3.2 build, also with AP's patch.
Even using xgcc/cc1 from the stage 1 boostrap build of 4.3.2
showed the bug (there was nothing extra interesting in the
diagnostics produced).
'configure' was invoked with
'../gcc-4.3.2/configure' '--prefix=/usr' '--libexecdir=/usr/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-libada'
'--enable-libssp' '--disable-werror' '--with-mpfr=/usr' '--with-gmp=/usr'
'--with-datarootdir=/usr/share' '--with-docdir=/usr/share/gcc-4.3.2/doc'
'--with-pdfdir=/usr/share/gcc-4.3.2/doc'
'--with-htmldir=/usr/share/gcc-4.3.2/doc/html' '--disable-coverage'
'--enable-nls' '--enable-__cxa_atexit' '--enable-decimal-float'
'--disable-fixed-point' '--enable-threads=posix' '--enable-clocale=gnu'
'--enable-shared' '--disable-intermodule'
'--enable-languages=ada,c++,fortran,java,objc,obj-c++,treelang,c'
'--with-local-prefix=/usr' '--with-gnu-ld' '--with-demangler-in-ld'
'--with-gnu-as' '--with-system-libunwind' '--with-system-zlib'
'--enable-bootstrap'
All those single quotes derive from my build scripts, which quote-and-
escape everything in sight. The actual CPU is an Athlon64 X2 5600+
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37872
[Bug c/30260] Enumeration types and enumeration constants erroneously given unsigned types
--- Comment #9 from manu at gcc dot gnu dot org 2008-10-19 13:55 --- Fixed for GCC 4.4 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
[Bug c/37872] ICE in extract_bit_field_1
--- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 13:57 --- *** This bug has been marked as a duplicate of 37870 *** -- bernard at brenda-arkle dot me dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37872
[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1
--- Comment #2 from bernard at brenda-arkle dot me dot uk 2008-10-19 13:57 --- *** Bug 37872 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #12 from pault at gcc dot gnu dot org 2008-10-19 14:34 --- To put the arguments succinctly, this is a double problem (apart from the conformity issue): (i) The original test case is losing the EXPR_PARENTHESES for some reason. ie. there is no question that in this case a temporary should be made for the 'FROM' actual argument. (ii) 12.7.3Elemental subroutine actual arguments An elemental subroutine is one that has only scalar dummy arguments, but may have array actual arguments. In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them. In the case that the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments are arrays, the values of the elements, if any, of the results are the same as would be obtained if the subroutine had been applied separately, in any order, to corresponding elements of each array actual argument. In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an elemental subroutine must satisfy the restrictions of 12.4.1.6. Since the 'TO' and 'FROM' arguments can alias in MVBITS and the results must be order independent, the test case should also create a temporary, even without enclosing parentheses. For the reason described before trans-stmt.c(gfc_conv_elemental_dependencies) this should be the 'TO' variable and should be done on the basis of a dependency between 'TO' and 'FROM' to be safe. The implementation is complicated by the resolved_sym for MVBITS not carrying formal arguments so that gfc_conv_elemental_dependencies does nothing, even if it is spoon-fed the call. Paul puts thinking hat on! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #10 from pault at gcc dot gnu dot org 2008-10-19 14:34 --- Fixed as obvious on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug c/37873] New: ICE in extract_bit_field_1
Reproducing this is easy.
cat ICE.sample.c 'EOF'
typedef unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
unsigned xxx(long double arg)
{
struct
{
char dummy[8];
unsigned yyy:7;
} copy;
memcpy(copy, arg, sizeof(copy));
return copy.yyy;
}
EOF
invoking 'gcc -c -O1 sample.c' then emits
/home/bernard/ICE.sample.c: In function xxx:
/home/bernard/ICE.sample.c:8: internal compiler error: in extract_bit_field_1,
at expmed.c:1271
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is quite sensitive! Small changes make the ICE
go away. These include
using -O0
re-sizing the array member dummy[] in the struct
Replacing the memcpy() with an assignment via a
cast pointer:
give the struct a tag (e.g., struct fimbulwinter)
copy = *((struct fimbulwinter *)arg)
renaming memcpy() at both occurrences to by-pass the built-in
The last is suggestive, no?
This is NOT a duplicate of bug 37269, though the ICE is reported from
the same function. I get the same behaviour after applying Andrew
Pinski's patch for that bug. In fact, I found this bug in an echt
4.3.1 bootstrap build, applied AP's patch, still had it, then used
that compiler to bootstrap a 4.3.2 build, also with AP's patch.
Even using xgcc/cc1 from the stage 1 boostrap build of 4.3.2
showed the bug (there was nothing extra interesting in the
diagnostics produced).
'configure' was invoked with
'../gcc-4.3.2/configure' '--prefix=/usr' '--libexecdir=/usr/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-libada'
'--enable-libssp' '--disable-werror' '--with-mpfr=/usr' '--with-gmp=/usr'
'--with-datarootdir=/usr/share' '--with-docdir=/usr/share/gcc-4.3.2/doc'
'--with-pdfdir=/usr/share/gcc-4.3.2/doc'
'--with-htmldir=/usr/share/gcc-4.3.2/doc/html' '--disable-coverage'
'--enable-nls' '--enable-__cxa_atexit' '--enable-decimal-float'
'--disable-fixed-point' '--enable-threads=posix' '--enable-clocale=gnu'
'--enable-shared' '--disable-intermodule'
'--enable-languages=ada,c++,fortran,java,objc,obj-c++,treelang,c'
'--with-local-prefix=/usr' '--with-gnu-ld' '--with-demangler-in-ld'
'--with-gnu-as' '--with-system-libunwind' '--with-system-zlib'
'--enable-bootstrap'
All those single quotes derive from my build scripts, which quote-and-
escape everything in sight. The actual CPU is an Athlon64 X2 5600+
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37873
[Bug c/37873] ICE in extract_bit_field_1
--- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39 --- I'm really sorry - requesting the form after network problems apparently submits it again! Is this itself a bug in the UI? *** This bug has been marked as a duplicate of 37870 *** -- bernard at brenda-arkle dot me dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37873
[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1
--- Comment #3 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39 --- *** Bug 37873 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #13 from domob at gcc dot gnu dot org 2008-10-19 14:46 --- Paul, thanks for stepping into the party :) My plan for working on this is to look at the first part of the problem for now (the lost parentheses, this is a general ELEMENTAL problem, as my (invalid) test from comment #7 also fails for adding parentheses around the first argument). I hope this can be fixed quite straight forward if I find the problem. After this, we can look at the MVBITS specific part. I think this is a reasonable way to work on this problem; what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:29 --- Subject: Bug 37863 Author: jvdelisle Date: Sun Oct 19 15:28:25 2008 New Revision: 141227 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141227 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37863 Backport from trunk. * io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly. 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 Backport from trunk. * io/list_read.c (nml_get_obj_data): If the first namelist object rank is greater than zero, call nml_object_read with the first object rather than the sub-object. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c branches/gcc-4_3-branch/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37863
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:29 --- Subject: Bug 37707 Author: jvdelisle Date: Sun Oct 19 15:28:25 2008 New Revision: 141227 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141227 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37863 Backport from trunk. * io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly. 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 Backport from trunk. * io/list_read.c (nml_get_obj_data): If the first namelist object rank is greater than zero, call nml_object_read with the first object rather than the sub-object. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c branches/gcc-4_3-branch/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:31 --- Subject: Bug 37707 Author: jvdelisle Date: Sun Oct 19 15:30:32 2008 New Revision: 141228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141228 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_54.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_54.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:39 --- (In reply to comment #22) default: - dtp-u.p.nml_delim = '\0'; + dtp-u.p.nml_delim = ''; wouldn't it be easier/faster to simply remove the whole switch and use simply dtp-u.p.nml_delim = ''; without special cases for the current delim status? Yes that would work, but I would like to allow users to use apostrophe if they wish. How about this? dtp-u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : ''; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:43 --- Fixed on 4.3 and 4.4 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37863
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #26 from toon at moene dot indiv dot nluug dot nl 2008-10-19 16:11 --- The patch works for my case, Please be careful with the namelist_18,f90 test case - I can't off-hand say whether it's right or (an extension). Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #14 from domob at gcc dot gnu dot org 2008-10-19 16:16 --- Actually, the parentheses aren't lost and *do* get honoured, but the temporary is only inside the scalarization loop and thus not the full array temporary we want; the problem is that the actual argument expressions (and thus the EXPR_OP) gets translated inside gfc_conv_function_call which is only inside the scalarization loop for ELEMENTAL calls and thus only a scalar temporary. A possible approach for solving this problem in a way that looks more or less clean to me would be to translate call expression arguments in gfc_trans_call before gfc_conv_function_call, i.e. before even generating the ELEMENTAL scalarization loop. This would however of course be a somewhat intrusive patch and I want to make sure you agree with this plan. Or is there some other way I'm not aware of? I'm just thinking that moving this expression translation that would take care of parentheses and friends would not involve any new code but rather reorganize the existing one and thus utilize what's already there to its best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug target/35574] [4.4 regression] unrecognizable insn generated for vector move
--- Comment #5 from kazu at gcc dot gnu dot org 2008-10-19 16:48 --- Posted a revised patch. See the patch URL above. -- kazu at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2008- |patches/2008- |10/msg00114.html|10/msg00787.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
Re: [Bug c/37873] ICE in extract_bit_field_1
Sent from my iPhone On Oct 19, 2008, at 7:39 AM, bernard at brenda-arkle dot me dot uk [EMAIL PROTECTED] wrote: --- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39 --- I'm really sorry - requesting the form after network problems apparently submits it again! Is this itself a bug in the UI? To some extend it is a bug in the browser which you are using. *** This bug has been marked as a duplicate of 37870 *** -- bernard at brenda-arkle dot me dot uk changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37873
[Bug c/37873] ICE in extract_bit_field_1
--- Comment #2 from pinskia at gmail dot com 2008-10-19 17:24 --- Subject: Re: ICE in extract_bit_field_1 Sent from my iPhone On Oct 19, 2008, at 7:39 AM, bernard at brenda-arkle dot me dot uk [EMAIL PROTECTED] wrote: --- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39 --- I'm really sorry - requesting the form after network problems apparently submits it again! Is this itself a bug in the UI? To some extend it is a bug in the browser which you are using. *** This bug has been marked as a duplicate of 37870 *** -- bernard at brenda-arkle dot me dot uk changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37873 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37873
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2008-10-19 18:16 --- The namelist_18.f90 test change is because we are now defaulting to a quote delimiter. We do not write a namelist without character string delimiters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug fortran/37834] write(*,'(f0.0)') 0.0 prints . instead of 0.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-19 18:36 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37834
[Bug fortran/37834] write(*,'(f0.0)') 0.0 prints . instead of 0.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-19 18:37 --- Subject: Bug 37834 Author: jvdelisle Date: Sun Oct 19 18:36:21 2008 New Revision: 141231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141231 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37834 * io/write_float.def (output_float): Emit '0.' for special case of format specifier 'f0.0' and value of zero. Likewise emit '0' for 'f1.0'. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37834
[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x y;
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-19 22:54 --- Subject: Bug 37004 Author: manu Date: Sun Oct 19 22:53:01 2008 New Revision: 141233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141233 Log: 2008-10-20 Manuel López-Ibáñez [EMAIL PROTECTED] PR c++/37004 cp/ * typeck.c (cp_common_type): New. The same as type_after_usual_arithmetic_conversions but without promotions. (type_after_usual_arithmetic_conversions): Do the promotions and call cp_common_type. (common_type): Make it behave like the C version of this function. Do not handle pointer types. (common_pointer_type): Move handling of pointer types from common_type to here. (cp_build_binary_op): Use common_pointer_type instead of common_type in call to pointer_diff. Use cp_common_type instead of common_type. * cp-tree.h (common_pointer_type): Declare. testsuite/ * g++.dg/warn/Wconversion-pr34389.C: Remove XFAIL. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wconversion-pr34389.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x y;
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-19 22:55 --- Fixed in GCC 4.4 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
[Bug c/37874] New: gcc sometimes accepts attribute in identifier list
GCC rejects the former, but not the later. void f2(y, __attribute__(()) x); void f3(__attribute__(()) x, y); -- Summary: gcc sometimes accepts attribute in identifier list Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #1 from sabre at nondot dot org 2008-10-20 01:08 --- It also accepts this: void f4(__attribute__(())); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #2 from joseph at codesourcery dot com 2008-10-20 01:51 --- Subject: Re: gcc sometimes accepts attribute in identifier list On Mon, 20 Oct 2008, sabre at nondot dot org wrote: It also accepts this: void f4(__attribute__(())); This is documented in Attribute Syntax. (The acceptance of empty attributes, and only empty attributes, at the start of an identifier list, is an implementation accident accurately carried over from the old parser without noticing it was there, but also a bug.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #3 from sabre at nondot dot org 2008-10-20 02:10 --- as it turns out, f3 could also be considered valid in c89... because it makes x and y be implicit int's, not an identifier list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #16 from nemet at gcc dot gnu dot org 2008-10-20 03:54 ---
I'm seeing this with mips64octeon-linux-gnu as well.
I think the problem is that in
ccp_fold_builtin():
2502memset (val, 0, sizeof (val));
2503for (i = 0; i nargs; i++)
2504 {
2505if ((arg_mask i) 1)
arg_mask is an int and in the testcase nargs is 35. Therefore the result of
the shift can be undefined. I will start testing a fix soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #17 from nemet at gcc dot gnu dot org 2008-10-20 04:21 --- I'm testing a patch. -- nemet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nemet at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED GCC host triplet|[EMAIL PROTECTED] | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
