[Bug c/20532] New: Bad code for DImode left shifts by 31 and then 1
gcc (GCC) 4.0.0 20050316 (prerelease) (from the gcc-4_0-branch branch) emits
bad code for DImode left shifts by 31 and then 1 (foo << 31 <<1). Instead of
doing the shifts, both the lowpart (correctly) and the highpart (incorrectly)
word get zeroed. If the shifts are replaced by ones by 30 and then 2 or by one
by 32, then the resulting code is correct.
GCC has been built with the following configure and make options:
$ CC=i386-linux-gcc \
CXX=i386-linux-g++ \
F77=i386-linux-gfortran \
CFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CXXFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
FCFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CC_FOR_BUILD=i386-linux-gcc \
CFLAGS_FOR_BUILD="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CXXFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
FCFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
INSTALL_PROGRAM='${INSTALL} -s' \
../configure --prefix=/usr --mandir='${datadir}/man' \
--with-local-prefix='${prefix}/local' \
--enable-shared \
--with-slibdir=/lib \
--enable-static \
--with-system-zlib \
--enable-threads \
--cache-file=config.cache \
--build=i386-linux --host=i386-linux --target=i386-linux
$ make 'BOOT_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'STAGE1_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'GCJFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CXX_FOR_BUILD=i386-linux-g++ \
'CXXFLAGS_FOR_BUILD=-pipe -O2 -fomit-frame-pointer -mtune=i486' bootstrap
Here is a simple test case that fails for me (the source C file only as you
seem not to want to receive *.s files):
unsigned long long int badshift(unsigned long long int v)
{
return v << 31 << 1;
}
The problem was originally discovered with a 4.0.0 snapshot from the trunk
dated 20050225, therefore it likely applies to 4.1.0, too.
--
Summary: Bad code for DImode left shifts by 31 and then 1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs 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=20532
[Bug c/20532] Bad code for DImode left shifts by 31 and then 1
--- Additional Comments From macro at linux-mips dot org 2005-03-18 13:50 --- You need to pass at least -O1 when building this program to trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20532
[Bug rtl-optimization/20532] [4.0/4.1 Regression] Bad code for DImode left shifts by 31 and then 1
--- Additional Comments From macro at linux-mips dot org 2005-03-23 12:15 --- > + (v * (((HOST_WIDE_ITN)1 << 31) + ((HOST_WIDE_INT)1 << 31))) ^^^ There is a typo above. Thanks for your fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20532
[Bug driver/23861] New: Build failure due to "-pipe" not working with .F90 and .F95 files
Bootstrapping with Fortran enabled fails for 4.0.1 if "-pipe" is included
among flags passed through to library builds. It used to work for 4.0.0.
The reason is "libgfortran/intrinsics/f2c_specifics.F90", which is new to
4.0.1, and the "%|" operator used in the specs
("gcc/fortran/lang-specs.h") which does not expect numeric characters:
/home/macro/src/redhat/BUILD/gcc-4.0.1/obj/gcc/gfortran
-B/home/macro/src/redhat/BUILD/gcc-4.0.1/obj/gcc/ -B/usr/i386-linux/bin/
-B/usr/i386-linux/lib/ -isystem /usr/i386-linux/include -isystem
/usr/i386-linux/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I.
-iquote../../../libgfortran/io -Wall -fno-repack-arrays -fno-underscoring
-pipe -O2 -fomit-frame-pointer -mtune=i486 -c
../../../libgfortran/intrinsics/f2c_specifics.F90 -fPIC -o
.libs/f2c_specifics.o
cc1: warning: command line option "-fno-repack-arrays" is valid for F95
but not for C
cc1: warning: command line option "-fno-underscoring" is valid for F95
but not for C
f951: error: unrecognized command line option "-95"
The following patch fixes the problem for me -- digits should be safe to
accept in file names, shouldn't they?
2005-08-22 Maciej W. Rozycki <[EMAIL PROTECTED]>
* gcc.c (do_spec_1): Accept numeric characters in file name
suffixes.
Tested successfully in a native bootstrap for "i386-linux-gnu" for GCC
4.0.1. Inspection of sources shows it is needed for HEAD as well.
--
Summary: Build failure due to "-pipe" not working with .F90 and
.F95 files
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug driver/23861] Build failure due to "-pipe" not working with .F90 and .F95 files
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:03 --- Created an attachment (id=9718) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9718&action=view) gcc-4.0.1-specs-pipe-suffix.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug fortran/23862] New: Select Fortran source form appropriately for "-pipe"
When "-pipe" is used for .F90 and .F95 sources this warning is produced: Warning: Reading file '' as free form. The reason is the compiler cannot deduce the form from the file name suffix as in this case it's only known to the preprocessor. Here is an obvious patch following the approach used for .F/.fpp/.FPP and .f/.for/.FOR files. 2005-08-22 Maciej W. Rozycki <[EMAIL PROTECTED]> * fortran/lang-specs.h: Pass "-ffree-form" by default for Fortran 90 sources. Tested successfully in a native bootstrap for "i386-linux-gnu" for GCC 4.0.1. Inspection of sources shows it is needed for HEAD as well. -- Summary: Select Fortran source form appropriately for "-pipe" Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: macro at linux-mips dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug fortran/23862] Select Fortran source form appropriately for "-pipe"
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:06 --- Created an attachment (id=9719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9719&action=view) gcc-4.0.1-fortran-form-free.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug driver/23861] Build failure due to "-pipe" not working with .F90 and .F95 files
--- Comment #4 from macro at linux-mips dot org 2005-10-10 15:08 --- The patch has been applied. -- macro at linux-mips dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-08-08 17:42 --- Richard, Thanks for your work (for bug 21291). Unfortunately it's not enough for this case. It doesn't seem to work for the "g" constraint used there, but that might probably be considered just a shortcoming -- "=rm" or "rmi" can be used instead as appropriate. But more importantly it doesn't work with an early clobber and that's something that cannot be avoided -- GCC has to be told that a register, if used, is to be destroyed early. To summarize, the case does not work as is -- with "=&g" and "g". It does not work with "=&rm" and "g". It does work with "=rm" and "g", but it's dangerous as GCC will probably allocate both the same register. It does work with "=m" and "g", but it sort of misses the point. I removed the "register" keyword from the affected variables for these tests as it is problematic for the "=m" case (the keyword should be safe to be removed from glibc now, as it requires at least GCC 3.2 these days). Please let me know if that's clear enough. Or whether I should reopen the other (duplicate) bug rather than this one. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-08-09 11:38
---
Thanks for your insight. I did some experimenting with the code (including
reducing the source file to a somewhat more readable form -- I can post it
if interested) and I noticed this *(struct { char __x[0xfff]; } *) cast
is somehow involved. I searched the info pages to find out what exactly it
is expected to mean to GCC, but I failed. Anyway I sense this effectively
tells all the memory (0xfff is close to 1/16 of the target's address
space) is potentially to be referred to, forcing any variables cached in
registers to be written back to their corresponding memory locations. Am I
right?
But "__d3" is a temporary and if located on the stack, it's not going to
affect "__s" in a well-defined program. Is there a way to tell GCC about
that?
Of course it can be worked around by using "=m" as the constraint for
"__d3", but then the opportunity to use a register when one is actually
available is lost. I've tried to use alternative constraints with an early
clobber for the register variation only (i.e. "=&r,m"), but GCC still
insisted on using a register.
BTW, thanks for the hint about calling strcspn() -- I've noticed the
problem disappears when one of these calls is removed, too. I'll prepare a
patch for glibc as a microoptimization here. But of course
is a user header, so we cannot simply cover the problem by changing
md5-crypt.c and praying it won't reappear elsewhere. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-08-09 18:23 --- Please make sure you look at the right variant, i.e. "sysdeps/i386/bits/string.h", as there are different versions for different i386 submodels. Still the version in the glibc tree differs a bit indeed, but it's even worse, absolutely demanding five registers and as a result breaking a glibc build much earlier. What has been included in this report is my attempt to rectify the problem with glibc. See the discussion starting at: "http://sourceware.org/ml/libc-alpha/2005-06/msg00026.html"; for a reference. Given your explanation I guess the only way to make this code work is to force "__d3" into memory, which essentially means the code needs to be rethought. Unless we find a better way for providing hints to the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug ada/21937] New: Member record alignment triggering an ICE
This problem happens for platforms that set STRICT_ALIGNMENT. For them it is
possible for a given record type to be expressed using an integer mode if used
as a member record, and the BLK mode if used standalone. As a result an
assignment where lhs is BLKmode and rhs is *Imode may be generated and this
triggers an ICE.
I've been able to trigger it for 4.0.0 using alpha-linux-gnu,
mipsel-linux-gnu and mips64el-linux cross-compilers run on i386-linux-gnu
as well as a native mipsel-linux-gnu one. The compiler was configured as
follows:
$ CC=i386-linux-gcc \
CXX=i386-linux-g++ \
F77=i386-linux-gfortran \
CFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CXXFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
FCFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CC_FOR_BUILD=i386-linux-gcc \
CFLAGS_FOR_BUILD='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
CXXFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
FCFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
INSTALL_PROGRAM='${INSTALL} -s' \
../configure --prefix=/usr '--mandir=${datadir}/man' \
'--with-local-prefix=${prefix}/alpha-linux/local' \
--disable-multilib \
--enable-shared \
--enable-static \
--with-system-zlib \
--enable-threads \
--cache-file=config.cache \
--build=i386-linux --host=i386-linux --target=alpha-linux
then built as follows:
$ make 'BOOT_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'GCJFLAGS=-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
CXX_FOR_BUILD=i386-linux-g++ \
'CXXFLAGS_FOR_BUILD=-pipe -O2 -fomit-frame-pointer -mtune=i486' all
(this is for alpha-linux-gnu -- the others were built similarly; I can supply
details if needed).
I'm sending a set of sources that trigger the problem for me. They are
actually a part of the Ada binding of ncurses 5.4. To reproduce, build as
follows:
$ alpha-linux-gcc -c -gnatpn -pipe -O2 -fomit-frame-pointer \
terminal_interface-curses.adb
I've been able to track the problem down to the alignment of member records
being increased implicitly in an attempt to fit them into an integer mode.
I believe it is incorrect as it changes the alignment of the containing
record as well and therefore it changes the ABI. That would be true e.g. for
the MIPS ABI as far as C is concerned, but I don't know if Ada follows the
same rules, so my opinion is not definite. Anyway I've prepared a patch
proposal that fixes the problem for me.
Please consider.
--
Summary: Member record alignment triggering an ICE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-linux-gnu
GCC host triplet: i386-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-06 20:43 --- Created an attachment (id=9041) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9041&action=view) This is the set of the sources -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-06 20:45 --- Created an attachment (id=9042) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9042&action=view) gcc-4.0.0-ada-record-pack-align.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 10:28 --- Here are details missing from the original report (sorry about that). This is output from the compiler when the ICE happens: 4.0.0 (alpha-unknown-linux-gnu) GCC error: in simplify_subreg, at simplify-rtx.c:3726 Error detected at terminal_interface-curses.adb:2559:1 [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387 This is a ChangeLog entry for the patch: 2005-06-07 Maciej W. Rozycki <[EMAIL PROTECTED]> * ada/decl.c (make_packable_type): Use the same alignment for the new type. Finally, as I have a native compiler for an affected platform, specifically mipsel-linux-gnu, I have run the Ada testsuite both without and with the patch applied and the change hasn't introduced any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 12:14 --- > That's not quite true, the type is not the same. It's hard to argue for me as Ada is not a language I'm familiar with, but the problematic assignment is: return Ch.Attr; in Get_Character_Attribute() and both Ch.Attr and the return value of the function are declared as Character_Attribute_Set, so I guess they are both of the same type, aren't they. > How does that change the ABI for the containing record type? The type is laid > out only once. As for members, this is only done for non-aliased members so > ABI > considerations are irrelevant. Of course it changes the ABI -- if any member of a record (which is an equivalent to a C structure) gets its alignment increased, then the alignment of the containing record (structure) gets adjusted appropriately. Otherwise the member's record alignment requirement couldn't possibly be satisfied at the link time. And of course the alignment does matter for platforms that care about alignment as different machine code may be needed to access data. > > 2005-06-07 Maciej W. Rozycki <[EMAIL PROTECTED]> > > > > * ada/decl.c (make_packable_type): Use the same alignment for the > > new > > type. > > That would defeat the purpose of make_packable_type. If I understand code correctly compute_record_mode() should still be able to use one of the integer modes for platforms that don't care about alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] [4.0 Regression] Member record alignment triggers an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 18:16 --- > > Of course it changes the ABI -- if any member of a record (which is an > > equivalent to a C structure) gets its alignment increased, then the > > alignment > > of the containing record (structure) gets adjusted appropriately. > > Sure, but since all records of this type will be laid out the same way, where > is > the problem? This only happens for packed records or records with After a short consideration I agree -- it would only be a problem if the case was reversed, i.e. standalone records got their alignment bumped while member oned did not. > representation clauses, both not bound to any ABI rules as far as Ada is concerned. Well, there may be no written standard for this case, but there is always an ABI, even if limited to GCC. > > If I understand code correctly compute_record_mode() should still be able to > > use one of the integer modes for platforms that don't care about alignment. > > x86 is not (yet) the only platform out there. :-) Well, you may have noticed I'm already aware of this -- otherwise I wouldn't have filed the report in the first place. But the problem is the i386 is probably the architecture most code is primarily tested with and unfortunately it has quite forgiving restrictions about alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug inline-asm/22045] New: can't find a register in class 'GENERAL_REGS'
This seems a bit different to the two other bugs in this class, so I'm filing it separately. For the attached code (extracted from glibc, with some modifications), built with: $ i386-linux-gcc md5-crypt.i -c -O2 -pipe -fPIC -fomit-frame-pointer -o md5-crypt.os (-fomit-frame-pointer given for illustration only) GCC runs out of registers, even though the problematic asm insists on having four registers available only. That means at least one free register is still available (there would be two if alloca() didn't consume %ebp) -- how many is GCC meant to require? What's interesting, replacing the "=&g" constraint for "__d3" with "=m" (a patch attached for clarity) makes the failure go away, so it looks like it is really a wrong one. -- Summary: can't find a register in class 'GENERAL_REGS' Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: macro at linux-mips dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-linux-gnu GCC host triplet: i386-linux-gnu GCC target triplet: i386-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-06-13 13:32 --- Created an attachment (id=9078) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9078&action=view) This is the problematic source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-06-13 13:33 --- Created an attachment (id=9079) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9079&action=view) This makes the error go away -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-06-13 14:14 --- There is no other software involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'
--- Additional Comments From macro at linux-mips dot org 2005-06-13 14:44 --- I haven't written it's an ICE, have I? Unfortunately I can't see a way of rewriting the asm such that an appropriate variant is used depending on whether there are six or five or four (or fewer?) registers available. What is the reasonable upper limit for the number of registers used by an asm for the i386 -- I can't recall it being documented anywhere (for such a register-starved platform it might be worth doing)? It seems four are still too many, sigh... BTW, this is old code that used to work just fine with 2.95 and older despite actually requesting five registers. I've rewriten it to please GCC 4.0 and it has fixed the original place of failure elsewhere in glibc, but it still breaks for this file. I've now checked it with 3.3.5 and 3.4.4 -- it works with the former and breaks with the latter. I suppose it's hard for people to get code right when a given version of GCC happens to work (be it intentionally or accidentally) and a later one stops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
