Many vectorization failures on my x86_64 lto bootstrap.
Compare the log file of the test runs from my lto bootstrap: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00832.html to that of a normal x86_64 bootstrap: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00790.html What log files, if any, would be helpful to hunt this down ? -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Many vectorization failures on my x86_64 lto bootstrap.
Hello! Compare the log file of the test runs from my lto bootstrap: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00832.html Platform: x86_64-unknown-linux-gnu configure flags: ... --with-arch=native --with-tune=native to that of a normal x86_64 bootstrap: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00790.html Platform: x86_64-unknown-linux-gnu configure flags: ... --with-arch=core2 --with-cpu=core2 What log files, if any, would be helpful to hunt this down ? You have AVX capable machine, and --with-arch=native enables 256 bit vectorization behind your back. The vectorizer testcases are not prepared for an internal rerun of vectorization and - since each internal report merges it own dump to the report -- scan-tree-dump-times fail. So, testsuite issue. Uros.
Re: the struggle to create a 64-bit gcc on Solaris 10
I can not see my error here and am wondering what the issue is. Obviously, if you have 32-bit object files in your build tree, you're using a 32-bit compiler. Which very likely means that you didn't set CC and CXX. -- Eric Botcazou
Re: Many vectorization failures on my x86_64 lto bootstrap.
On 11/10/2012 01:08 PM, Uros Bizjak wrote: You have AVX capable machine, and --with-arch=native enables 256 bit vectorization behind your back. OK, I will make that more explicit with march=corei7-avx in my next runs. So the lto bootstrap is a red herring in this regard - good to know. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Time for GCC 5.0? (TIC)
On 11/10/2012 04:45 AM, NightStrike wrote: Making c99 the default for gcc would be a great candidate for this. IIUC, gcc without -std=c99 will compile for c89. And if I read the manual correctly, it's because c99 isn't finished yet. gcc 5.0 should have a complete c99. Should in what sense? The missing features are either library issues that we can't do anything about or things that no-one cares about enough to fix. GCC is, to all intents and purposes, C99 compatible. See http://gcc.gnu.org/c99status.html Andrew.
Re: Time for GCC 5.0? (TIC)
On Fri, 9 Nov 2012, NightStrike wrote: Making c99 the default for gcc would be a great candidate for this. IIUC, gcc without -std=c99 will compile for c89. And if I read the manual correctly, it's because c99 isn't finished yet. gcc 5.0 should have a complete c99. The reason gnu99 is not the default is not that certain corner cases of extended identifiers do not work ideally (in particular regarding handling of different source-code spellings of the same UCN) and so extended identifiers are still in their own option rather than enabled by default for C99 and C++, it's that there is no warning option to warn about C90/C99 incompatibilities when compiling in gnu99 mode to at least the extent -pedantic diagnoses things when compiling in gnu89 mode. Given such a warning option I think it would be reasonable to make gnu99 the default. -- Joseph S. Myers jos...@codesourcery.com
Re: the struggle to create a 64-bit gcc on Solaris 10
Eric wrote:
Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
You're up against three factors here. First, the sparc64 platform ABI
specifies 32-bit executables unless the user specifically asks for
64-bit. I'm really unclear on why you think that's a bad thing (spacv9
gives all the benefits of 64-bit, including 64-bit regs, but without the
space blow-up that comes from 64-bit pointers). It's useful enough that
the x86 world is replicating it with x32. However, if you're really
determined to have 64-bit only,
CC='cc -m64' and CXX='CC -m64' ./configure --build=sparc64-sun-solaris2.10
usually does the trick (you didn't mention which compiler you're using
to bootstrap, I assume suncc). You'll want to do that with gmp/mpfr/mpc
as well, because gcc is pretty picky that they have *exactly* the same
target triple.
Another issue is preventing gcc from attempting a 32-bit multilib, since
it wants to be able to generate both 32- and 64-bit code (as per the
platform ABI). Passing --disable-multilib takes care of that.
The last (very annoying) issue is that when gcc bootstraps itself, the
freshly-built compiler doesn't generate 64-bit binaries by default.
BOOT_CFLAGS can work around that: http://gcc.gnu.org/install/build.html.
CC='cc -m64' CXX='CC -m64' ../gmp-5.0.1-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared
CC='cc -m64' CXX='CC -m64' ../mpfr-3.1.1-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared --with-gmp=$HOME/apps/gcc-4.7.2
CC='cc -m64' CXX='CC -m64' ../mpc-0.8.2-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared --with-{gmp,mpfr}=$HOME/apps/gcc-4.7.2
CC='cc -m64' CXX='CC -m64' ../gcc-4.7.2-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-multilib --with-{gmp,mpfr,mpc}=$HOME/apps/gcc-4.7.2
--without-gnu-{as,ld}
make {CFLAGS_FOR_TARGET,BOOT_CFLAGS}='-m64 -O2'
$ file $HOME/apps/gcc-4.7.2/bin/gcc
gcc: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked,
not stripped, no debugging information available
$ $HOME/apps/gcc-4.7.2/bin/gcc hello.c
$ file ./a.out
a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped, no debugging information available
Notes:
- Use mpfr-3.1.1 or newer, older versions are broken on sparc-solaris
(linker errors involving alloca)
- Build the support libs with --disable-shared to avoid strange
TLS-related loader errors
- Disable -g to avoid linker errors mentioning R_SPARC_UA32 and
.rela.debug_info during stage 3
Ryan
Re: the struggle to create a 64-bit gcc on Solaris 10
Eric wrote: Any pointers at all as to the error of my ways ? http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 You're up against three factors here. First, the sparc64 platform ABI specifies 32-bit executables unless the user specifically asks for 64-bit. I'm really unclear on why you think that's a bad thing (spacv9 It isn't. In fact, it has never been a problem for me in the past. Furthermore I have been doingbuilds of GCC on Solaris for a long long time now. Decade. Maybe more. Can't recall to be honest. Usually I have no problem and like to post my results. See solaris 8 results at http://gcc.gnu.org/gcc-4.7/buildstat.html However, Solaris 8 was the old gold standard. anything that built there, ran everywhere in the Solaris world. At least for anything in the last ten years. Consider the compiler I am using here : $ ls -lap $CC -rwxr-xr-x 1 root bin 640388 Aug 11 2010 /opt/csw/gcc4/bin/gcc $ file /opt/csw/gcc4/bin/gcc /opt/csw/gcc4/bin/gcc: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ elfdump -vd $CC Version Needed Section: .SUNW_version fileversion libc.so.1 SUNW_1.18.1 Dynamic Section: .dynamic index tagvalue [0] NEEDED0x2973 libc.so.1 [1] INIT 0x36150 [2] FINI 0x3616c [3] RUNPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [4] RPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [5] HASH 0x100e8 [6] STRTAB0x13ce0 [7] STRSZ 0x29d9 [8] SYMTAB0x114f0 [9] SYMENT0x10 [10] CHECKSUM 0x88ef [11] VERNEED 0x166bc [12] VERNEEDNUM0x1 [13] PLTRELSZ 0x48c [14] PLTREL0x7 [15] JMPREL0x16730 [16] RELA 0x166dc [17] RELASZ0x4e0 [18] RELAENT 0xc [19] DEBUG 0 [20] FEATURE_1 0x1 [ PARINIT ] [21] FLAGS 0 0 [22] FLAGS_1 0 0 [23] PLTGOT0x63544 [24] NULL 0 $ See that version need section in the output binary gcc ? To me this compiler works just fine and has for a few years now. It is really well tested and was released a while back. Note, however, the version needed for libc.so.1. See that SUNW_1.18.1 ? Well to someone in the know, that is a dead give away that this was compiled on Solaris 8. That version NEEDED was released quite a while ago. If you had a baseline version of Solaris 8 and then patched it up to date you would have a libc no higher than 1.18.1 or maybe 1.19. This means the resultant binaries created on that platform are assured to have access to the system calls and baseline functions provided in all libraries that follow in Solaris 9 and 10 and even Solaris 11. Let's take a look at the libc in Solaris 10 : $ ls -lapb /lib/libc.so.1 -rwxr-xr-x 1 root bin 1653368 Aug 21 17:34 /lib/libc.so.1 $ elfdump -vd /lib/libc.so.1 Version Definition Section: .SUNW_version index version dependency [1] libc.so.1[ BASE ] [2] SUNW_1.23 SUNW_1.22.7 [3] SUNW_1.22.7 SUNW_1.22.6 [4] SUNW_1.22.6 SUNW_1.22.5 [5] SUNW_1.22.5 SUNW_1.22.4 [6] SUNW_1.22.4 SUNW_1.22.3 [7] SUNW_1.22.3 SUNW_1.22.2 [8] SUNW_1.22.2 SUNW_1.22.1 [9] SUNW_1.22.1 SUNW_1.22 [10] SUNW_1.22 SUNW_1.21.3 [11] SUNW_1.21.3 SUNW_1.21.2 [12] SUNW_1.21.2 SUNW_1.21.1 [13] SUNW_1.21.1 SUNW_1.21 [14] SUNW_1.21 SUNW_1.20.4 [15] SUNW_1.20.4 SUNW_1.20.1 [16] SUNW_1.20.1 SUNW_1.20 [17] SUNW_1.20 SUNW_1.19 [18] SUNW_1.19 SUNW_1.18.1 [19] SUNW_1.18.1 SUNW_1.18
Re: the struggle to create a 64-bit gcc on Solaris 10
On 10/11/2012 3:51 PM, Dennis Clarke wrote:
Eric wrote:
Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
You're up against three factors here. First, the sparc64 platform ABI
specifies 32-bit executables unless the user specifically asks for
64-bit. I'm really unclear on why you think that's a bad thing (spacv9
It isn't.
Then why is it bad to have a 32-bit gcc? I'm really confused now.
I've had a 32-bit gcc producing 64-bit binaries without complaint on a
Niagara II machine for about three years now. Recent versions of gcc
aren't even hard to bring up any more. All the stuff I wrote in my email
was about not doing the easy way, and instead bootstrapping a gcc that
is itself a 64-bit binary and produces only 64-bit executables.
snipped detailed rant
To make a long story short, it is a drag to deal wwith such crap when I just
want a compiler that looks like, walks like and acts like the one in my RHEL 6
workstation at home.
The only difference I've noticed with a stock sparc-solaris gcc is that
thread-local storage is dog slow (blame the ABI) and dbx usually can't
handle dwarf debug info correctly. I've actually had *far* more multilib
pain from linux over the years than solaris. Plus, most multilib pain I
have suffered in Solaris was due to autotools projects from the linux
world insisting on dropping 64-bit libraries in $PREFIX/lib instead of
$PREFIX/lib/sparcv9. I've never even heard of half the stuff you
mentioned ($ISALIST mumble mumble, version needed mumble mumble), and
yet multilib development has somehow been working all right so far.
snipped some more
So I have a whole pile of GNU stuff on my production nice shiney new Niagara
Sparc server and I can not find a reason to care about 32-bit anything.
So why not try a full 64-bit GNU toolchain?
... because it's an awful lot of work for something you claim not to
care about?
CC='cc -m64' CXX='CC -m64' ../gmp-5.0.1-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared
CC='cc -m64' CXX='CC -m64' ../mpfr-3.1.1-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared --with-gmp=$HOME/apps/gcc-4.7.2
CC='cc -m64' CXX='CC -m64' ../mpc-0.8.2-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-shared --with-{gmp,mpfr}=$HOME/apps/gcc-4.7.2
CC='cc -m64' CXX='CC -m64' ../gcc-4.7.2-src/configure
--prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
--disable-multilib --with-{gmp,mpfr,mpc}=$HOME/apps/gcc-4.7.2
--without-gnu-{as,ld}
make {CFLAGS_FOR_TARGET,BOOT_CFLAGS}='-m64 -O2'
$ file $HOME/apps/gcc-4.7.2/bin/gcc
gcc: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked,
not stripped, no debugging information available
nice !
$ $HOME/apps/gcc-4.7.2/bin/gcc hello.c
$ file ./a.out
a.out: ELF 64-bit MSB executable SPARCV9 Version 1,
dynamically
linked, not stripped, no debugging information available
yeah but a 32-bit gcc can do that just fine.
You said you didn't want a 32-bit gcc, that having 32-bit anything
around was a liability. Hence the directions to make a purely 64-bit one.
snipped yet more stuff
pain.
been there .. done that .. over and over.
(linker errors involving alloca)
- Build the support libs with --disable-shared to avoid strange
TLS-related loader errors
- Disable -g to avoid linker errors mentioning R_SPARC_UA32 and
.rela.debug_info during stage 3
I am rapidly coming to the conclusion that this won't be easy to do .. but I'll
keep hacking at it.
I don't think you understand: I used the above configury incantation to
bring up, from scratch, a purely 64-bit gcc that produces 64-bit
binaries by default. Today. On a Niagara II machine. No 32-bit ELF files
anywhere. Hence the delay in responding and the notes about gotchas I
encountered along the way.
If that's not what you were looking for, what is?
Ryan
Re: the struggle to create a 64-bit gcc on Solaris 10
On 10 November 2012 20:51, Dennis Clarke wrote: So 32-bit gcc works just fine. However I need a pile of libs all over the place ( gmp, mpfr, mpc, etc etc ) for this to work No you don't. If you put gmp, mpfr and mpc in the GCC source tree, or install them with --disable-shared, then you don't need to keep the libs around.
Re: the struggle to create a 64-bit gcc on Solaris 10
On 10/11/2012 4:54 PM, Jonathan Wakely wrote: On 10 November 2012 20:51, Dennis Clarke wrote: So 32-bit gcc works just fine. However I need a pile of libs all over the place ( gmp, mpfr, mpc, etc etc ) for this to work No you don't. If you put gmp, mpfr and mpc in the GCC source tree, or install them with --disable-shared, then you don't need to keep the libs around. You know, somehow I'd missed that gcc would build the numerical libs for you if they were in tree... I'd only heard about the host tools (binutils, etc.). Does it do the same for all deps (e.g. readline) as well? That will save a fair bit of configury work next time! Ryan
Re: the struggle to create a 64-bit gcc on Solaris 10
On 10 November 2012 22:08, Ryan Johnson wrote: You know, somehow I'd missed that gcc would build the numerical libs for you if they were in tree... I'd only heard about the host tools (binutils, etc.). Does it do the same for all deps (e.g. readline) as well? No. The contrib/download_prerequisites script will fetch the gmp, mpfr and mpc code and put it in the tree. See http://gcc.gnu.org/wiki/InstallingGCC for more.
gcc-4.7-20121110 is now available
Snapshot gcc-4.7-20121110 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121110/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 193396 You'll find: gcc-4.7-20121110.tar.bz2 Complete GCC MD5=a10870436d306db4ec6f360cf42375e2 SHA1=46c60e0cede4033ef6c72e1b734a8ffc8abcf79f Diffs from 4.7-20121103 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Time for GCC 5.0? (TIC)
On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley a...@redhat.com wrote: On 11/10/2012 04:45 AM, NightStrike wrote: Making c99 the default for gcc would be a great candidate for this. IIUC, gcc without -std=c99 will compile for c89. And if I read the manual correctly, it's because c99 isn't finished yet. gcc 5.0 should have a complete c99. Should in what sense? The missing features are either library issues that we can't do anything about or things that no-one cares about enough to fix. GCC is, to all intents and purposes, C99 compatible. See http://gcc.gnu.org/c99status.html The manual doesn't imply that: -std=gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will become the default. So from the perspective of the user reading the manual entry for the gnu99 option, the only feedback is 1) c99 isn't done, and 2) there's some plan to finish it and then make it the default. You seem to imply that it's as done as it'll ever realistically be. Sounds kind of conflicting.
[Bug tree-optimization/55260] New: [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 Bug #: 55260 Summary: [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28650 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28650 reduced testcase Compiler output: $ gcc -O2 -std=gnu++0x -fno-inline -fipa-cp-clone testcase.C testcase.C:20:1: internal compiler error: in ipa_get_parm_lattices, at ipa-cp.c:263 } ^ 0x59033c ipa_get_parm_lattices /mnt/svn/gcc-trunk/gcc/ipa-cp.c:263 0x129c1e5 ipa_get_parm_lattices /mnt/svn/gcc-trunk/gcc/ipa-cp.c:2908 0x129c1e5 cgraph_edge_brings_all_agg_vals_for_node /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3082 0x129c1e5 perhaps_add_new_callers /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3134 0x129c1e5 decide_about_value /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3207 0x129dfd0 decide_whether_version_node /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3315 0x129dfd0 ipcp_decision_stage /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3441 0x129dfd0 ipcp_driver /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3483 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193368 - fail 4.7 r191640 - OK
[Bug target/55258] SSE register isn't used for 16byte copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 08:52:22 UTC --- Created attachment 28651 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28651 Something like this
[Bug c++/55261] New: [C++0x] ICE (SIGSEGV) when inheriting implicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55261 Bug #: 55261 Summary: [C++0x] ICE (SIGSEGV) when inheriting implicit constructor Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28652 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28652 reduced testcase I don't know if the code is valid. Compiler output: $ gcc testcase.C -std=c++11 testcase.C:4:8: internal compiler error: Segmentation fault struct B : A ^ 0xbc2e9f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:333 0x6579f9 vec_ttree_node*::operator[](unsigned int) /mnt/svn/gcc-trunk/gcc/vec.h:487 0x6579f9 add_implicitly_declared_members /mnt/svn/gcc-trunk/gcc/cp/class.c:3016 0x65e2b4 check_bases_and_members /mnt/svn/gcc-trunk/gcc/cp/class.c:5343 0x663321 finish_struct_1(tree_node*) /mnt/svn/gcc-trunk/gcc/cp/class.c:6237 0x66558c finish_struct(tree_node*, tree_node*) /mnt/svn/gcc-trunk/gcc/cp/class.c:6545 0x69413e cp_parser_class_specifier_1 /mnt/svn/gcc-trunk/gcc/cp/parser.c:18231 0x69413e cp_parser_class_specifier /mnt/svn/gcc-trunk/gcc/cp/parser.c:18440 0x69413e cp_parser_type_specifier /mnt/svn/gcc-trunk/gcc/cp/parser.c:13568 0x6ab3cd cp_parser_decl_specifier_seq /mnt/svn/gcc-trunk/gcc/cp/parser.c:10893 0x6aee09 cp_parser_simple_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10492 0x6b0e57 cp_parser_block_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10441 0x6ba23b cp_parser_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10338 0x6b886d cp_parser_declaration_seq_opt /mnt/svn/gcc-trunk/gcc/cp/parser.c:10224 0x6b8b62 cp_parser_translation_unit /mnt/svn/gcc-trunk/gcc/cp/parser.c:3796 0x6b8b62 c_parse_file() /mnt/svn/gcc-trunk/gcc/cp/parser.c:28144 0x7bdbe4 c_common_parse_file() /mnt/svn/gcc-trunk/gcc/c-family/c-opts.c:1007 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:15:32 UTC --- (In reply to comment #2) (define_insn *movti_internal_rex64 [(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m) (match_operand:TI 1 general_operand riFo,riF,C,xm,x))] TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1])) Uros, is this change ok for you? If it is ok I can commit the patch only on Wednesday (I'll be away for a few days). Yes, the change looks correct to me. I'll take care of the patch.
[Bug c++/55262] New: [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55262
Bug #: 55262
Summary: [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Created attachment 28653
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28653
preprocessed source
Compiler output:
$ gcc inh-ctor10.ii -std=c++11 -g
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor10.C: In constructor
'B::B(Ts ...) [with Ts = {int}]':
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor10.C:10:12: internal
compiler error: Segmentation fault
using A::A;
^
0xbc2e9f crash_signal
/mnt/svn/gcc-trunk/gcc/toplev.c:333
0x5eb3bb function_parameter_expanded_from_pack_p(tree_node*, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:2869
0x8c826d gen_formal_parameter_pack_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17119
0x8c826d gen_subprogram_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17943
0x8ce15c gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19990
0x8cbe34 dwarf2out_abstract_function
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17429
0x8ce148 gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19947
0x8cf6f8 dwarf2out_function_decl
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20380
0x94416c rest_of_handle_final
/mnt/svn/gcc-trunk/gcc/final.c:4324
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-193368-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-193368-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.8.0 20121109 (experimental) (GCC)
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:22:03 UTC --- (In reply to comment #3) There are 2 issues here: 1. Should we use movdqu(%eax), %xmm0# 19*movti_internal_rex64/4[length = 5] movdqa%xmm0, (%rsp)# 29*movti_internal_rex64/5[length = 5] to copy 16 bytes? Yes, and this is the intention of all these ! marks. 2. Should we split *movti_internal_rex64 if -mno-sse is used? Movti is used for TARGET_64BIT only. Please keep in mind that *_doubleword instructions operate on TImode values, so we rely completely on register allocator to NOT allocate XMM register moves in this case. According to the documentation, ! means that alternative is OK if no reloading is needed, so this fits our purpose to use SSE moves unless we move value directly to TImode arithmetic operation (*_doubleword patterns).
[Bug middle-end/55263] New: [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Bug #: 55263 Summary: [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28654 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28654 autoreduced testcase The ICE at the same place as PR54385, but that one is FIXED now. Compiler output: $ gcc -O -fgcse-after-reload -fnon-call-exceptions testcase.C testcase.C: In function 'void foo()': testcase.C:65:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:875 } ^ 0x827274 pre_and_rev_post_order_compute(int*, int*, bool) /mnt/svn/gcc-trunk/gcc/cfganal.c:875 0x7e19b9 init_alias_analysis() /mnt/svn/gcc-trunk/gcc/alias.c:2852 0xaddc9a gcse_after_reload_main /mnt/svn/gcc-trunk/gcc/postreload-gcse.c:1274 0xaddc9a rest_of_handle_gcse2 /mnt/svn/gcc-trunk/gcc/postreload-gcse.c:1321 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193368 - crash 4.7 r191640 - OK
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #9 from uros at gcc dot gnu.org 2012-11-10 11:28:17 UTC --- Author: uros Date: Sat Nov 10 11:28:12 2012 New Revision: 193388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193388 Log: PR target/55247 * config/i386/i386.md (*movti_internal_rex64): Add ! to riF-o alternative. testsuite/ChangeLog: PR target/55247 * gcc.target/i386/pr55247.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55247.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 Component|rtl-optimization|middle-end Ever Confirmed|0 |1 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 11:47:05 UTC --- Recategorizing due to middle-end issue, see comment #5 and #6.
[Bug middle-end/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 11:55:55 UTC --- ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp)
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 12:15:14 UTC --- (In reply to comment #20) Please can the RMs have a new look at this. This is tuning decision, and I see Intel folks in the CC. I see no problem in changing these defaults, if they are supported by some benchmark results.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org 2012-11-10 12:55:43 UTC --- It looks like Jakub's patch fixed this completely. I now see -mavx: vorpd, vorpd, vorps -mavx2: vorpd, vorpd, vpor so closing.
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #22 from Mikael Pettersson mikpe at it dot uu.se 2012-11-10 13:36:46 UTC --- Created attachment 28655 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28655 another test case I'm using a construct similar to the 'f1' function of the initial test case to set the low 8 or 16 bits of a 32-bit register in a CPU emulator of mine, and the code generated by gcc 4.6/4.7/4.8 for this on x86_64 is appalling. In the attached test case, the setb1 and setw1 functions use bit and/or operations, while the setb2 and setw2 functions assign the sub-field directly via a union. gcc compiles each set*2 function to a single mov (+ ret), while each set*1 function becomes 5 instructions (+ ret).
[Bug tree-optimization/55264] New: [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Bug #: 55264 Summary: [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28656 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28656 preprocessed source (g++.dg/tree-ssa/pr45453.C) Compiler output: $ gcc -O2 -fno-early-inlining -fno-weak pr45453.ii /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr45453.C:16:1: internal compiler error: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 } ^ 0xa220d7 ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*) /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2141 0xa29cec try_make_edge_direct_virtual_call /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2245 0xa29cec update_indirect_edges_after_inlining /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2316 0xa29cec propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2356 0xa29c2e propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2360 0xa29f08 ipa_propagate_indirect_call_infos(cgraph_edge*, vec_tcgraph_edge***) /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2386 0x12a7864 inline_call(cgraph_edge*, bool, vec_tcgraph_edge***, int*, bool) /mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:259 0x12a6932 inline_small_functions /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1609 0x12a6932 ipa_inline /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1791 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193387 - crash 4.7 r191640 - crash 4.6 r191640 - crash 4.5 r191640 - OK
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #26 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-10 14:38:03 UTC --- Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate.
[Bug middle-end/55266] New: vector expansion: 36 movs for 4 adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
Bug #: 55266
Summary: vector expansion: 36 movs for 4 adds
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
I already mentioned this example, but I don't think it is in any PR:
typedef double vec __attribute__((vector_size(4*sizeof(double;
void f(vec*x){
*x+=*x+*x;
}
compiled with -S -O3 -msse4, produces 4 add insns (normal), and 36 mov insns,
which is a bit much... For comparison, this should be equivalent to the
following code, which generates only 6 mov insn:
typedef double vec __attribute__((vector_size(2*sizeof(double;
void f(vec*x){
x[0]+=x[0]+x[0];
x[1]+=x[1]+x[1];
}
One minor enhancement would be to have fold_ternary handle BIT_FIELD_REF of
CONSTRUCTOR of vectors (I think it is already tracked elsewhere, though I
couldn't find it).
But the main issue is with copying these fake vectors. Their fake registers
are in memory, and copying between those (4 times 2 movs going through rax in
DImode, I assume it is faster than going through xmm registers?) isn't
optimized away. In this example, the content of *x is first copied to a fake
register. Then V2DF parts are extracted, added, and put in memory. That fake
register is now copied to a new fake register. V2DF are taken from it, added to
the V2DF that were still there, and stored to memory. And that is finally
copied to the memory location x.
I don't know how that should be improved. Maybe the vector lowering pass should
go even further, turn the first program into the second one, and not leave any
extra long vectors for the back-end to handle? It doesn't seem easy to optimize
in the back-end, too late. Or maybe something can be done at expansion time?
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-10 17:07:57 UTC --- With current trunk (r193391) I see a different ICE: /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr45453.C:16:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269 0xec0114 inline_call(cgraph_edge*, bool, vec_tcgraph_edge***, int*, bool) /home/polacek/src/gcc/gcc/ipa-inline-transform.c:269 0xebefb8 inline_small_functions /home/polacek/src/gcc/gcc/ipa-inline.c:1553 0xebf492 ipa_inline /home/polacek/src/gcc/gcc/ipa-inline.c:1735 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/55267] New: double operation giving different results depending on context and optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267
Bug #: 55267
Summary: double operation giving different results depending on
context and optimization level
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jkuittinen293...@gmail.com
/*
* the following code outputs :o on 4.7.2 when compiled with -O0
* and :) when compiled with -O1
*
*/
#include iostream
class Plap
{
public:
double value;
Plap(int a, int b)
{
value = (double)a / (double)b;
}
};
int main()
{
int i = 1;
int j = 3;
Plap plap(i, j);
if (plap.value != ((double)i / (double)j))
std::cout :o std::endl;
else
std::cout :) std::endl;
return 0;
}
[Bug c++/55267] double operation giving different results depending on context and optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 17:49:20 UTC --- I bet this is a dup of bug 323.
[Bug middle-end/55263] [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 CC||mpolacek at gcc dot ||gnu.org, steven at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-10 18:24:15 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=190602
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 18:32:27 UTC --- Author: pinskia Date: Sat Nov 10 18:32:23 2012 New Revision: 193393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193393 Log: 2012-11-10 Andrew Pinski apin...@cavium.com PR bootstrap/55202 * configure.ac: Set PLUGIN_LD_SUFFIX to just ld if it was ld-new or collect-ld. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 18:32:51 UTC --- Fixed.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |UNCONFIRMED Component|middle-end |rtl-optimization Depends on||55259 Ever Confirmed|1 |0 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 19:02:04 UTC --- (In reply to comment #11) ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp) This is related to PR 55259. This patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html fixes it.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 19:11:03 UTC --- (In reply to comment #12) (In reply to comment #11) ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp) This is related to PR 55259. This patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html fixes it. With this fix, we don't need to change *movti_internal_rex64 since it generates redundant load/store.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #14 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 19:41:31 UTC --- (In reply to comment #13) With this fix, we don't need to change *movti_internal_rex64 since it generates redundant load/store. True, IIRC this was the reason for asymmetry in alternatives. Please revert the *movti_internal_rex64 change when the middle-end patch goes in.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #27 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-10 20:21:41 UTC --- (In reply to comment #26) Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10 22:58:16 UTC --- Hum, I am not sure why the macro unwinder avoids unwinding if the macro comes from a system-header. If a warning message comes from a system-header, then it should have been suppressed earlier and never reach the macro unwinder. Otherwise, we already have emitted the diagnostic, so the macro unwinder just provides more context.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10 23:10:32 UTC --- On the other hand, let's consider: pr55252.c: #define bar 256 #include pr55252.h pr55252.h: #pragma GCC system_header signed char foo = bar; In this case, I would expect the warning to be suppressed (as it is with -ftrack-macro-expansion=0). However, since the warning is actually given in the C file, it is emitted. I am getting more and more convinced that expanding to spelling point might not be the best (I think Paolo Bonzini raised this issue at the time...). On the other hand, this is a very contrived testcase. I wouldn't expect in normal code that the expansion point to be in a system-header and the spelling point in a non-system-header. Dodji, what do you think?
[Bug tree-optimization/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 Chris Lundquist clundquist at bluebox dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Chris Lundquist clundquist at bluebox dot net 2012-11-10 23:11:04 UTC --- Fixed in latest release. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper Target: x86_64-apple-darwin12 Configured with: ../gcc-4.8-20121104/configure --prefix=/opt/local --build=x86_64-apple-darwin12 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8-20121104_0' Thread model: posix gcc version 4.8.0 20121104 (experimental) (MacPorts gcc48 4.8-20121104_0)
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-10
23:20:36 UTC ---
(In reply to comment #4)
On the other hand, this is a very contrived testcase. I
wouldn't expect in normal code that the expansion point to be in a
system-header and the spelling point in a non-system-header.
It's not that contrived, here's a more realistic example:
#define fixed 1
#include iostream
int main() { }
This gives a very unhelpful error:
t.cc:1:15: error: expected unqualified-id before numeric constant
#define fixed 1
^
t.cc:1:15: error: expected unqualified-id before numeric constant
#define fixed 1
^
t.cc:1:15: error: expected initializer before numeric constant
[Bug middle-end/55263] [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-11-10 23:59:39 UTC --- Index: postreload.c === --- postreload.c(revision 193396) +++ postreload.c(working copy) @@ -2289,8 +2289,9 @@ rest_of_handle_postreload (void) reload_cse_regs (get_insns ()); /* Reload_cse_regs can eliminate potentially-trapping MEMs. Remove any EH edges associated with them. */ - if (cfun-can_throw_non_call_exceptions) -purge_all_dead_edges (); + if (cfun-can_throw_non_call_exceptions + purge_all_dead_edges ()) +cleanup_cfg (0); return 0; }
[Bug target/55268] New: gcc4.8 mingw-w64 Wrong stdcall import symbols generated after rev 193204
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55268 Bug #: 55268 Summary: gcc4.8 mingw-w64 Wrong stdcall import symbols generated after rev 193204 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: squall...@gmail.com Warning: resolving __imp__GetModuleHandleA by linking to __imp__GetModuleHandleA@4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving __imp__VirtualProtect by linking to __imp__VirtualProtect@16 Warning: resolving __imp__Sleep by linking to __imp__Sleep@4 Warning: resolving __imp__GetLastError by linking to __imp__GetLastError@0 Warning: resolving __imp__TlsGetValue by linking to __imp__TlsGetValue@4 Warning: resolving __imp__GetCurrentThreadId by linking to __imp__GetCurrentThreadId@0 Warning: resolving __imp__VirtualQuery by linking to __imp__VirtualQuery@12 E:/msys/src/gcc/trunk/build/gcc/crtbegin.o:cygming-crtbegin.c:(.text+0x35): undefined reference to `_imp__GetProcAddress' gthr-win32_s.o: In function `_gthr_win32_key_create': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:105: undefined reference to `_imp__TlsAlloc' gthr-win32_s.o: In function `_gthr_win32_key_delete': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:123: undefined reference to `_imp__TlsFree' gthr-win32_s.o: In function `_gthr_win32_getspecific': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:133: undefined reference to `_imp__SetLastError' gthr-win32_s.o: In function `_gthr_win32_setspecific': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:140: undefined reference to `_imp__TlsSetValue' gthr-win32_s.o: In function `_gthr_win32_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:150: undefined reference to `_imp__CreateSemaphoreA' gthr-win32_s.o: In function `_gthr_win32_mutex_destroy': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:156: undefined reference to `_imp__CloseHandle' gthr-win32_s.o: In function `_gthr_win32_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:163: undefined reference to `_imp__WaitForSingleObject' gthr-win32_s.o: In function `_gthr_win32_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:187: undefined reference to `_imp__ReleaseSemaphore' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:198: undefined reference to `_imp__CreateSemaphoreA' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:215: undefined reference to `_imp__WaitForSingleObject' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:256: undefined reference to `_imp__ReleaseSemaphore' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_destroy': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:265: undefined reference to `_imp__CloseHandle' unwind-dw2-fde_s.o: In function `_gthread_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:638: undefined reference to `_imp__CreateSemaphoreA' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function `_gthread_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function `_gthread_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function
[Bug treelang/55269] New: Rename tree_node complex field to avoid conflict with C99 complex type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269 Bug #: 55269 Summary: Rename tree_node complex field to avoid conflict with C99 complex type Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: treelang AssignedTo: unassig...@gcc.gnu.org ReportedBy: pe...@colberg.org Dear GCC developers, The identifier of the union field tree_complex complex of union tree_node in tree.h potentially conflicts with the macro #define complex _Complex defined in C99 complex.h. I stumbled over this issue while writing a plugin for GCC using the foreign function interface of LuaJIT. LuaJIT predefines C99 complex types, both _Complex and complex. Therefore LuaJIT rejects tree_complex complex of tree_node as a declaration with an invalid declaration. Could the tree_complex field be renamed, e.g., to complex_cst? (The suggestion stems from the name of the macro COMPLEX_CST_CHECK.) Regards, Peter
[Bug treelang/55269] Rename tree_node complex field to avoid conflict with C99 complex type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-11 06:21:55 UTC --- In 4.8, GCC is now written in C++ rather than C, so I don't think it matter anymore as there is no macro define in C++ for complex.
[Bug target/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC|mikpe at it dot uu.se | --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2012-11-11 07:55:49 UTC --- Fixed by r193052, aka PR54957. However, testing is now made more difficult due to r193032, aka PR52015 -- apparently one now needs bleeding edge mingw-w64 headers to build gcc-4.8 for x86_64-w64-mingw32.
Re: libstdc++ PATCH to use __cplusplus rather than __GXX_EXPERIMENTAL_CXX0X__
Ed Smith-Rowland 3dw...@verizon.net ha scritto: Paolo? ... carte blanche to Jason! (but I have a little lexer tweak pending... ;) Paolo
Re: [asan] Patch - fix an ICE in asan.c
On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote: * I still have to do an all-language bootstrap and regtesting, though the latter is probably pointless as there is currently not a single -fasan test case. --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 +++ gcc/asan.c2012-11-09 21:26:00.0 +0100 @@ -1362,6 +1362,8 @@ transform_statements (void) instrument_assignment (i); else if (is_gimple_call (s)) maybe_instrument_call (i); + if (gsi_end_p (i)) + break; } } } That looks a wrong place for this. Instead, maybe_instrument_call should ensure that *iter is set to the last stmt that shouldn't be instrumented. instrument_derefs does that correctly, so assignments and __atomic/__sync builtins should be correct (*iter is set to the assignment/call), for strlen call it seems to DTRT, but for other builtin calls it would leave *iter elsewhere. As we want to scan for accesses the rest of the bb that contained the call (but that bb after splitting already is above the highest bb number to be insturmented), we need to keep *iter at the call we just processed, so if there are say two consecutive calls the second one is going to be processed. So untested: 2012-11-10 Jakub Jelinek ja...@redhat.com * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. --- gcc/asan.c.jj 2012-11-02 00:09:22.0 +0100 +++ gcc/asan.c 2012-11-10 10:00:03.717715834 +0100 @@ -1191,6 +1191,7 @@ maybe_instrument_builtin_call (gimple_st else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); return true; } return false; Jakub
[PATCH, i386]: Fix PR 55247, ICE: Max. number of generated reload insns per insn is achieved
Hello!
Attached patch disparages riF-o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as offsetable. H.J. will propose a patch for
this [2].
2012-11-10 Vladimir Makarov vmaka...@redhat.com
Uros Bizjak ubiz...@gmail.com
PR target/55247
* config/i386/i386.md (*movti_internal_rex64): Add ! to riF-o
alternative.
testsuite/ChangeLog:
2012-11-10 Uros Bizjak ubiz...@gmail.com
PR target/55247
* gcc.target/i386/pr55247.c: New test.
Tested on x86_64-linux-gnu {,m32} and committed to mainline SVN.
[1] gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c2
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c6
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 193387)
+++ config/i386/i386.md (working copy)
@@ -1874,7 +1874,7 @@
(const_string OI)))])
(define_insn *movti_internal_rex64
- [(set (match_operand:TI 0 nonimmediate_operand =!r ,o ,x,x ,m)
+ [(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m)
(match_operand:TI 1 general_operand riFo,riF,C,xm,x))]
TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1]))
{
Index: testsuite/gcc.target/i386/pr55247.c
===
--- testsuite/gcc.target/i386/pr55247.c (revision 0)
+++ testsuite/gcc.target/i386/pr55247.c (working copy)
@@ -0,0 +1,38 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-options -O2 -mx32 -maddress-mode=long -mno-sse } */
+
+typedef unsigned int uint32_t;
+typedef unsigned int uintptr_t;
+typedef uint32_t Elf32_Word;
+typedef uint32_t Elf32_Addr;
+typedef struct {
+ Elf32_Word st_name;
+ Elf32_Addr st_value;
+ Elf32_Word st_size;
+ unsigned char st_other;
+} Elf32_Sym;
+typedef struct {
+ Elf32_Word r_info;
+}
+Elf32_Rela;
+typedef struct {
+ union {
+Elf32_Addr d_ptr;
+ }
+ d_un;
+} Elf32_Dyn;
+struct link_map {
+ Elf32_Dyn *l_info[34];
+};
+typedef struct link_map *lookup_t;
+extern void symbind32 (Elf32_Sym *);
+void
+_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
+{
+ const Elf32_Sym *const symtab = (const void *) (l)-l_info[6]-d_un.d_ptr;
+ const Elf32_Rela *const reloc = (const void *) ((l)-l_info[23]-d_un.d_ptr
+ reloc_arg * sizeof (Elf32_Rela));
+ const Elf32_Sym *refsym = symtab[((reloc-r_info) 8)];
+ const Elf32_Sym *defsym = refsym;
+ Elf32_Sym sym = *defsym;
+ symbind32 (sym);
+}
Re: [asan] Patch - fix an ICE in asan.c
Jakub Jelinek wrote: --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 +++ gcc/asan.c 2012-11-09 21:26:00.0 +0100 @@ -1362,6 +1362,8 @@ transform_statements (void) instrument_assignment (i); else if (is_gimple_call (s)) maybe_instrument_call (i); + if (gsi_end_p (i)) + break; } } } That looks a wrong place for this. I already expected that it was not fully correct ;-) So untested: Thanks for the patch! It fixed the problem half way: It fixes the second issue I had (fail10.ii, http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ). However, it didn't fix the original problem: As the call for strlen directly returns, it never reaches your patch. Hence, it doesn't fix fail31.ii of http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00786.html If one uses the same line for strlen, it works. Updated patches attached – one is on top of the trunk + Dodji's patches, the other is on top of the asan branch. * * * The question is whether one also needs to do something for the atomics handling in maybe_instrument_builtin_call, which has: instrument_derefs (iter, dest, loc, is_store); return; The instrument_derefs calls - in some cases - build_check_stmt, which in turn calls: *iter = gsi_start_bb (else_bb) Tobias (This patch is for the trunk after the asan integration patches.) 2012-11-10 Jakub Jelinek ja...@redhat.com Tobias Burnus bur...@net-b.de * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100 +++ gcc/asan.c 2012-11-10 13:44:51.0 +0100 @@ -1068,6 +1068,7 @@ instrument_builtin_call (gimple_stmt_ite case BUILT_IN_STRLEN: instrument_strlen_call (iter); + *iter = gsi_for_stmt (call); return; /* And now the __atomic* and __sync builtins. @@ -1307,6 +1308,7 @@ instrument_builtin_call (gimple_stmt_ite else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); } } (This patch is for the asan branch.) 2012-11-10 Jakub Jelinek ja...@redhat.com Tobias Burnus bur...@net-b.de * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. diff --git a/gcc/asan.c b/gcc/asan.c index 155e84b..3297b52 100644 --- a/gcc/asan.c +++ b/gcc/asan.c @@ -952,6 +952,7 @@ maybe_instrument_builtin_call (gimple_stmt_iterator *iter) case BUILT_IN_STRLEN: instrument_strlen_call (iter); + *iter = gsi_for_stmt (call); return true; /* And now the __atomic* and __sync builtins. @@ -1191,6 +1192,7 @@ maybe_instrument_builtin_call (gimple_stmt_iterator *iter) else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); return true; } return false;
*ping* [patch, fortran] PR 30146, errors for INTENT(OUT) and INTENT(INOUT) for DO loop variables
I wrote: after the dicsussion on c.l.f, it become clear that passing a DO loop variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error. The attached patch throws an error for both cases. I chose to issue the errors as a front-end pass because we cannot check for formal arguments during parsing (where the other checks are implemented). Regression-tested. OK for trunk? Ping ** 1.4285 ? Thomas
Re: libstdc++ PATCH to use __cplusplus rather than __GXX_EXPERIMENTAL_CXX0X__
On 9 November 2012 22:09, Jason Merrill wrote: Now that G++ uses the value of __cplusplus specified by the standard, we don't need the other macro anymore. OK for trunk, or should I save it for the next stage 1? Jason I'd been thinking about suggesting that change just the other day - do it!
[PATCH} AIX Testsuite cleanup
A few more testsuite fixes to address failures on AIX. The only
really interesting one is g++.dg/other/anon5.C where Undefined is
capitalized in the AIX error message.
Thanks, David
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
* c-c++-common/vector-compare-1.c: Same.
* c-c++-common/vector-compare-2.c: Same.
* g++.dg/other/unused1.C: Skip on AIX.
* g++.dg/other/anon5.C: Allow Undefined to be capitalized. Ignore
extra message on AIX.
Index: other/anon5.C
===
--- other/anon5.C (revision 193385)
+++ other/anon5.C (working copy)
@@ -1,6 +1,8 @@
// PR c++/34094
// { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
// { dg-options -g }
+// Ignore additional message on powerpc-ibm-aix
+// { dg-prune-output obtain more information } */
namespace {
struct c
@@ -11,7 +13,7 @@
const bool f()
{
- return c::t; // { dg-message undefined undefined { target *-*-* } 0 }
+ return c::t; // { dg-message \[Uu\]ndefined undefined { target
*-*-* } 0 }
// Some targets report the error for the previous line, others
// don't give line number inforamtion for it, so use line 0.
}
Re: PATCH: Handle ZERO_EXTEND offsettable address
Il 10/11/2012 07:44, H.J. Lu ha scritto:
Hi,
In
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
{*movti_internal_rex64}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 sym+0 S16 A64])
we fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
This patch adds ZERO_EXTEND support to adjust_address_1 and
offsettable_address_addr_space_p. Tested on Linux/x32. OK to install?
Is there any reason why SIGN_EXTEND should be handled differently?
(Just asking, I don't know this code well).
Paolo
Thanks.
H.J.
---
gcc/
2012-11-10 H.J. Lu hongjiu...@intel.com
PR rtl-optimization/55247
PR middle-end/55259
* emit-rtl.c (adjust_address_1): Handle ZERO_EXTEND.
* recog.c (offsettable_address_addr_space_p): Likewise.
gcc/testsuite/
2012-11-10 H.J. Lu hongjiu...@intel.com
PR rtl-optimization/55247
PR middle-end/55259
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 95bbfa7..d7c454c 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2109,6 +2109,12 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
plus_constant (address_mode,
XEXP (addr, 1), offset));
+ else if (GET_CODE (addr) == ZERO_EXTEND)
+ {
+ addr = XEXP (addr, 0);
+ addr = plus_constant (GET_MODE (addr), addr, offset);
+ addr = gen_rtx_ZERO_EXTEND (address_mode, addr);
+ }
else
addr = plus_constant (address_mode, addr, offset);
}
diff --git a/gcc/recog.c b/gcc/recog.c
index ee68e30..d3dd591 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -1934,15 +1934,21 @@ int
offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
addr_space_t as)
{
- enum rtx_code ycode = GET_CODE (y);
+ enum rtx_code ycode;
rtx z;
- rtx y1 = y;
+ rtx y1;
rtx *y2;
int (*addressp) (enum machine_mode, rtx, addr_space_t) =
(strictp ? strict_memory_address_addr_space_p
: memory_address_addr_space_p);
unsigned int mode_sz = GET_MODE_SIZE (mode);
+ if (GET_CODE (y) == ZERO_EXTEND)
+y = XEXP (y, 0);
+
+ ycode = GET_CODE (y);
+ y1 = y;
+
if (CONSTANT_ADDRESS_P (y))
return 1;
diff --git a/gcc/testsuite/gcc.target/i386/pr55247.c
b/gcc/testsuite/gcc.target/i386/pr55247.c
new file mode 100644
index 000..594139e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr55247.c
@@ -0,0 +1,35 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options -O -mno-sse -mno-mmx -mx32 -maddress-mode=long } */
+
+typedef unsigned int uint32_t;
+typedef uint32_t Elf32_Word;
+typedef uint32_t Elf32_Addr;
+typedef struct {
+ Elf32_Word st_name;
+ Elf32_Addr st_value;
+ Elf32_Word st_size;
+ unsigned char st_other;
+} Elf32_Sym;
+typedef struct {
+ Elf32_Word r_info;
+}
+Elf32_Rela;
+typedef struct {
+ union {
+Elf32_Addr d_ptr;
+ }
+ d_un;
+} Elf32_Dyn;
+struct link_map {
+ Elf32_Dyn *l_info[34];
+};
+extern void symbind32 (Elf32_Sym *);
+void
+_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
+{
+ const Elf32_Sym *const symtab = (const void *) l-l_info[6]-d_un.d_ptr;
+ const Elf32_Rela *const reloc = (const void *) (l-l_info[23]-d_un.d_ptr
+ reloc_arg * sizeof (Elf32_Rela));
+ Elf32_Sym sym = symtab[(reloc-r_info) 8];
+ symbind32 (sym);
+}
Re: [PATCH] Fix combined tree for LTO
Il 10/11/2012 05:30, Andrew Pinski ha scritto: Hi, The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not the final installed binary name. This patch fixes the problem by changing if we got ld-new to just ld. Note this issue has been around since 4.6 but not many people test installed binary and it does not show up while doing testing from the combined tree either. OK? Bootstrapped and tested with and without being in a combined tree without any regressions. OK with one change: please make it test collect-ld as well. Paolo Thanks, Andrew Pinski * configure.ac: Set PLUGIN_LD_SUFFIX to just ld if it was ld-new. * configure: Regenerate.
Re: [asan] Patch - fix an ICE in asan.c
Tobias Burnus wrote:
So untested:
Thanks for the patch! It fixed the problem half way: It fixes the
second issue I had (fail10.ii,
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ).
However, it didn't fix the original problem: As the call for strlen
directly returns, it never reaches your patch. Hence, it doesn't fix
fail31.ii of http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00786.html
If one uses the same line for strlen, it works.
I spoke too early. With the updated patch, there is no ICE, but one
crashes for the following valid program with:
==27313== ERROR: AddressSanitizer crashed on unknown address
0x13fffe8fc737 (pc 0x004008e3 sp 0x7fffa3f1c6d0 bp 0x7fffa3f1c700 T0)
AddressSanitizer can not provide additional info.
The crucial part is the strlen call.
#include stdio.h
#include string.h
int main(int argc, char *argv[])
{
int i;
for (i = 0; i argc; i++)
{
printf(%d: '%s':%zd\n, i, argv[i], strlen(argv[i]));
}
return 0;
}
Tobias
Re: [PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll
On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote: I had reckoned that the behaviour could be reverted to what was before while I figure out a way to get the warning in place for both cases, i.e. with tree-vrp (where max_loop_iterations now causes the loop to be folded away in -O2) and this unroll case (in -O1). I'll look at getting a warning for the tree-vrp case separately if the infinite loop behaviour needs to be retained. I'm sorry, I won't be able to get this done today. The patch causes a regression with torture/pr49518.c where it gives out the warning when it shouldn't. I had seen this warning earlier (with the earlier behaviour of not removing the exits) and fixed it, but it has reappeared now, perhaps due to some recent patch that removes more exits or something else. I'll get back on this late next week since I'll be offline for most of the week (it's holiday season here in India). Siddhesh
Fix fallout of patch for PR rtl-optimization/54315
In the patch I installed for PR rtl-optimization/54315:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00745.html
the special code dealing with BLKmode in registers at the beginning of
store_field is disabled for CALL_EXPR:
/* If we are storing into an unaligned field of an aligned union that is
in a register, we may have the mode of TARGET being an integer mode but
MODE == BLKmode. In that case, get an aligned object whose size and
alignment are the same as TARGET and store TARGET into it (we can avoid
the store if the field being stored is the entire width of TARGET). Then
call ourselves recursively to store the field into a BLKmode version of
that object. Finally, load from the object into TARGET. This is not
very efficient in general, but should only be slightly more expensive
than the otherwise-required unaligned accesses. Perhaps this can be
cleaned up later. It's tempting to make OBJECT readonly, but it's set
twice, once with emit_move_insn and once via store_field. */
if (mode == BLKmode
(REG_P (target) || GET_CODE (target) == SUBREG)
TREE_CODE (exp) != CALL_EXPR)
{
rtx object = assign_temp (type, 1, 1);
rtx blk_object = adjust_address (object, BLKmode, 0);
if (bitsize != (HOST_WIDE_INT) GET_MODE_BITSIZE (GET_MODE (target)))
emit_move_insn (object, target);
store_field (blk_object, bitsize, bitpos,
bitregion_start, bitregion_end,
mode, exp, type, MEM_ALIAS_SET (blk_object), nontemporal);
emit_move_insn (target, object);
/* We want to return the BLKmode version of the data. */
return blk_object;
}
because PR rtl-optimization/54315 is about useless spills to the stack for
BLKmode values returned in registers. I didn't realize that this change also
affects the other 2 kinds of targets, namely those returning BLKmode values by
means of PARALLEL and those returning BLKmode values in memory. It turns out
that the change introduced 2 ACATS failures on SPARC64 (former kind) and 1
ACATS failure on SPARC (letter kind) because of this oversight.
Therefore, the attached patch adds the missing bits to store_field for the
other 2 kinds of targets, thus fixing the introduced regressions. However,
the code used for the latter kind is generic, i.e. it doesn't require that the
object being stored be a value returned from a function. As such, it makes
the above block of code totally useless. So the patch removes it altogether,
which makes the TYPE parameter of store_field useless, which in turn makes
the same parameter of store_constructor_field useless as well.
Bootstrapped/regtested on x86_64-suse-linux, sparc64-sun-solaris2.9, sparc-
sun-solaris2.10, powerpc-linux-gnu, ia64-linux-gnu and mips64el-linux-gnu
and applied on the mainline.
2012-11-10 Eric Botcazou ebotca...@adacore.com
* expr.c (store_field): Remove TYPE parameter. Remove block of code
dealing with BLKmode in registers. Reimplement this support using
pseudo-registers and bit-field techniques.
(store_constructor_field): Remove TYPE parameter and adjust calls to
store_field.
(expand_assignment): Adjust calls to store_field. Add comment.
(store_expr): Add comment.
(store_constructor): Adjust calls to store_constructor_field.
(expand_expr_real_2): Adjust call to store_field.
--
Eric BotcazouIndex: expr.c
===
--- expr.c (revision 193322)
+++ expr.c (working copy)
@@ -137,12 +137,11 @@ static rtx compress_float_constant (rtx,
static rtx get_subtarget (rtx);
static void store_constructor_field (rtx, unsigned HOST_WIDE_INT,
HOST_WIDE_INT, enum machine_mode,
- tree, tree, int, alias_set_type);
+ tree, int, alias_set_type);
static void store_constructor (tree, rtx, int, HOST_WIDE_INT);
static rtx store_field (rtx, HOST_WIDE_INT, HOST_WIDE_INT,
unsigned HOST_WIDE_INT, unsigned HOST_WIDE_INT,
- enum machine_mode,
- tree, tree, alias_set_type, bool);
+ enum machine_mode, tree, alias_set_type, bool);
static unsigned HOST_WIDE_INT highest_pow2_factor_for_target (const_tree, const_tree);
@@ -4772,15 +4771,14 @@ expand_assignment (tree to, tree from, b
else if (bitpos + bitsize = mode_bitsize / 2)
result = store_field (XEXP (to_rtx, 0), bitsize, bitpos,
bitregion_start, bitregion_end,
- mode1, from, TREE_TYPE (tem),
+ mode1, from,
get_alias_set (to), nontemporal);
else if (bitpos = mode_bitsize / 2)
result = store_field (XEXP (to_rtx, 1), bitsize,
bitpos - mode_bitsize / 2,
bitregion_start, bitregion_end,
mode1, from,
- TREE_TYPE (tem), get_alias_set (to),
- nontemporal);
+ get_alias_set (to), nontemporal);
else if (bitpos == 0 bitsize == mode_bitsize)
{
rtx from_rtx;
@@ -4801,8 +4799,7
Invitation to use Google Talk
--- You've been invited by Claudiu Zissulescu to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-6d05ada042-4af1bd6b15-UsxLYA8higFMiMVCCKbLIKrPPKk To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/a-6d05ada042-4af1bd6b15-UsxLYA8higFMiMVCCKbLIKrPPKk?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team
Re: [1/8] Handle TRUNCATE in make_extraction
Tested as described in the covering note. OK to install? Richard gcc/ * combine.c (make_extraction): Handle TRUNCATEd INNERs. OK, thanks. -- Eric Botcazou
Re: [2/8] Add adjust_bitfield_address_size
Tested as described in the covering note. OK to install? Richard gcc/ * expr.h (adjust_address_1): Add a size parameter. (adjust_address, adjust_address_nv, adjust_bitfield_address) (adjust_bitfield_address_nv): Adjust accordingly. (adjust_bitfield_address_size): Define. * emit-rtl.c (adjust_address_1): Add a size parameter. Use it to set the size if MODE has no size. Check whether the size matches before returning the original memref. Require the size to be known for adjust_object. (adjust_automodify_address_1, widen_memory_access): Update calls to adjust_address_1. No objections by me. -- Eric Botcazou
Re: [3/8] Add narrow_bit_field_mem
Tested as described in the covering note. OK to install? Richard gcc/ * expmed.c (narrow_bit_field_mem): New function. (store_bit_field_using_insv, store_bit_field_1, store_fixed_bit_field) (extract_bit_field_1): Use it. This looks better now, thanks. -- Eric Botcazou
Re: [PATCH] Fix combined tree for LTO
On Sat, Nov 10, 2012 at 6:46 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 10/11/2012 05:30, Andrew Pinski ha scritto:
Hi,
The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
the final installed binary name. This patch fixes the problem by
changing if we got ld-new to just ld.
Note this issue has been around since 4.6 but not many people test
installed binary and it does not show up while doing testing from the
combined tree either.
OK? Bootstrapped and tested with and without being in a combined tree
without any regressions.
OK with one change: please make it test collect-ld as well.
Here is the patch which I applied.
Thanks,
Andrew Pinski
2012-11-10 Andrew Pinski apin...@cavium.com
PR bootstrap/55202
* configure.ac: Set PLUGIN_LD_SUFFIX to just ld if it was ld-new
or collect-ld.
* configure: Regenerate.
Paolo
Thanks,
Andrew Pinski
* configure.ac: Set PLUGIN_LD_SUFFIX to just ld if it was ld-new.
* configure: Regenerate.
Index: configure
===
--- configure (revision 193392)
+++ configure (working copy)
@@ -21343,6 +21343,12 @@ fi
ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
PLUGIN_LD_SUFFIX=`basename $gcc_cv_ld | sed -e s,$target_alias-,,`
+# if the PLUGIN_LD is set ld-new, just have it as ld
+# as that is the installed named.
+if test x$PLUGIN_LD_SUFFIX == xld-new \
+ || test x$PLUGIN_LD_SUFFIX == xcollect-ld ; then
+ PLUGIN_LD_SUFFIX=ld
+fi
# Check whether --with-plugin-ld was given.
if test ${with_plugin_ld+set} = set; then :
Index: configure.ac
===
--- configure.ac(revision 193392)
+++ configure.ac(working copy)
@@ -2003,6 +2003,12 @@ fi])
ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
PLUGIN_LD_SUFFIX=`basename $gcc_cv_ld | sed -e s,$target_alias-,,`
+# if the PLUGIN_LD is set ld-new, just have it as ld
+# as that is the installed named.
+if test x$PLUGIN_LD_SUFFIX == xld-new \
+ || test x$PLUGIN_LD_SUFFIX == xcollect-ld ; then
+ PLUGIN_LD_SUFFIX=ld
+fi
AC_ARG_WITH(plugin-ld,
[AS_HELP_STRING([[--with-plugin-ld=[ARG]]], [specify the plugin linker])],
[if test x$withval != x; then
Re: [PATCH, i386]: Fix PR 55247, ICE: Max. number of generated reload insns per insn is achieved
On Sat, Nov 10, 2012 at 3:43 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Attached patch disparages riF-o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as offsetable. H.J. will propose a patch for
this [2].
My updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html
2012-11-10 Vladimir Makarov vmaka...@redhat.com
Uros Bizjak ubiz...@gmail.com
PR target/55247
* config/i386/i386.md (*movti_internal_rex64): Add ! to riF-o
alternative.
testsuite/ChangeLog:
2012-11-10 Uros Bizjak ubiz...@gmail.com
PR target/55247
* gcc.target/i386/pr55247.c: New test.
Tested on x86_64-linux-gnu {,m32} and committed to mainline SVN.
[1] gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c2
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247#c6
Uros.
I checked in this patch to compile pr55247.c with -mno-sse -mno-mmx,
which triggers the bug.
H.J.
--
Index: ChangeLog
===
--- ChangeLog (revision 193393)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-11-10 H.J. Lu hongjiu...@intel.com
+
+ * gcc.target/i386/pr55247.c: Require maybe_x32 target. Add
+ -mno-sse -mno-mmx to dg-options. Reformat.
+
2012-11-10 David Edelsohn dje@gmail.com
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
Index: gcc.target/i386/pr55247.c
===
--- gcc.target/i386/pr55247.c (revision 193393)
+++ gcc.target/i386/pr55247.c (working copy)
@@ -1,8 +1,8 @@
/* { dg-do compile { target { ! { ia32 } } } } */
-/* { dg-options -O2 -mx32 -maddress-mode=long -mno-sse } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options -O2 -mno-sse -mno-mmx -mx32 -maddress-mode=long } */
typedef unsigned int uint32_t;
-typedef unsigned int uintptr_t;
typedef uint32_t Elf32_Word;
typedef uint32_t Elf32_Addr;
typedef struct {
@@ -16,7 +16,7 @@
}
Elf32_Rela;
typedef struct {
- union {
+ union {
Elf32_Addr d_ptr;
}
d_un;
@@ -24,15 +24,12 @@
struct link_map {
Elf32_Dyn *l_info[34];
};
-typedef struct link_map *lookup_t;
extern void symbind32 (Elf32_Sym *);
void
_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
{
- const Elf32_Sym *const symtab = (const void *) (l)-l_info[6]-d_un.d_ptr;
- const Elf32_Rela *const reloc = (const void *)
((l)-l_info[23]-d_un.d_ptr + reloc_arg * sizeof (Elf32_Rela));
- const Elf32_Sym *refsym = symtab[((reloc-r_info) 8)];
- const Elf32_Sym *defsym = refsym;
- Elf32_Sym sym = *defsym;
+ const Elf32_Sym *const symtab = (const void *) l-l_info[6]-d_un.d_ptr;
+ const Elf32_Rela *const reloc = (const void *)
(l-l_info[23]-d_un.d_ptr + reloc_arg * sizeof (Elf32_Rela));
+ Elf32_Sym sym = symtab[(reloc-r_info) 8];
symbind32 (sym);
}
libgo patch committed: Fix bug comparing struct field types
This patch fixes a bug comparing struct field types in the reflect
package. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 8b1f2a35ded1 libgo/go/reflect/type.go
--- a/libgo/go/reflect/type.go Tue Nov 06 10:44:51 2012 -0800
+++ b/libgo/go/reflect/type.go Sat Nov 10 12:20:00 2012 -0800
@@ -1309,8 +1309,19 @@
for i := range t.fields {
tf := t.fields[i]
vf := v.fields[i]
- if tf.name != vf.name || tf.pkgPath != vf.pkgPath ||
-tf.typ != vf.typ || tf.tag != vf.tag || tf.offset != vf.offset {
+ if tf.name != vf.name (tf.name == nil || vf.name == nil || *tf.name != *vf.name) {
+return false
+ }
+ if tf.pkgPath != vf.pkgPath (tf.pkgPath == nil || vf.pkgPath == nil || *tf.pkgPath != *vf.pkgPath) {
+return false
+ }
+ if tf.typ != vf.typ {
+return false
+ }
+ if tf.tag != vf.tag (tf.tag == nil || vf.tag == nil || *tf.tag != *vf.tag) {
+return false
+ }
+ if tf.offset != vf.offset {
return false
}
}
Re: PATCH: Handle ZERO_EXTEND offsettable address
On Sat, Nov 10, 2012 at 10:38:55AM -0800, H.J. Lu wrote:
On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 10/11/2012 07:44, H.J. Lu ha scritto:
Hi,
In
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
{*movti_internal_rex64}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 sym+0 S16
A64])
we fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
This patch adds ZERO_EXTEND support to adjust_address_1 and
offsettable_address_addr_space_p. Tested on Linux/x32. OK to install?
Is there any reason why SIGN_EXTEND should be handled differently?
(Just asking, I don't know this code well).
I don't have a testcase to show that we will generate SIGN_EXTEND
for offsettable address. I can add an assert of GET_CODE != SIGN_EXTEND.
This patch also handles SIGN_EXTEND. Tested on Linux/x32. OK to
install?
Thanks.
H.J.
---
gcc/
2012-11-10 H.J. Lu hongjiu...@intel.com
PR middle-end/55247
PR middle-end/55259
* emit-rtl.c (adjust_address_1): Handle ZERO_EXTEND and
SIGN_EXTEND.
* recog.c (offsettable_address_addr_space_p): Likewise.
* config/i386/i386.md (*movti_internal_rex64): Remove ! from
riF-o alternative.
gcc/testsuite/
2012-11-10 H.J. Lu hongjiu...@intel.com
PR middle-end/55247
PR middle-end/55259
* gcc.target/i386/pr55247-2.c: New file.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 2598a1f..243ab4e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1874,7 +1874,7 @@
(const_string OI)))])
(define_insn *movti_internal_rex64
- [(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m)
+ [(set (match_operand:TI 0 nonimmediate_operand =!r ,o ,x,x ,m)
(match_operand:TI 1 general_operand riFo,riF,C,xm,x))]
TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1]))
{
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 95bbfa7..22065f5 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2100,6 +2100,8 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
if (adjust_address)
{
+ rtx x;
+
/* If MEMREF is a LO_SUM and the offset is within the alignment of the
object, we can merge it into the LO_SUM. */
if (GET_MODE (memref) != BLKmode GET_CODE (addr) == LO_SUM
@@ -2109,6 +2111,20 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
plus_constant (address_mode,
XEXP (addr, 1), offset));
+ /* We permute zero/sign-extension and addition operation only if
+converting the constant does not change it. */
+ else if ((GET_CODE (addr) == ZERO_EXTEND
+ || GET_CODE (addr) == SIGN_EXTEND)
+ (x = GEN_INT (offset),
+ x == convert_memory_address_addr_space (address_mode,
+ x,
+ attrs.addrspace)))
+ {
+ enum rtx_code code = GET_CODE (addr);
+ addr = XEXP (addr, 0);
+ addr = plus_constant (GET_MODE (addr), addr, offset);
+ addr = gen_rtx_fmt_e (code, address_mode, addr);
+ }
else
addr = plus_constant (address_mode, addr, offset);
}
diff --git a/gcc/recog.c b/gcc/recog.c
index ee68e30..a916ef6 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -1934,15 +1934,22 @@ int
offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
addr_space_t as)
{
- enum rtx_code ycode = GET_CODE (y);
+ enum rtx_code ycode;
rtx z;
- rtx y1 = y;
+ rtx y1;
rtx *y2;
int (*addressp) (enum machine_mode, rtx, addr_space_t) =
(strictp ? strict_memory_address_addr_space_p
: memory_address_addr_space_p);
unsigned int mode_sz = GET_MODE_SIZE (mode);
+ /* Allow zero-extended or sign-extended address. */
+ if (GET_CODE (y) == ZERO_EXTEND || GET_CODE (y) == SIGN_EXTEND)
+y = XEXP (y, 0);
+
+ ycode = GET_CODE (y);
+ y1 = y;
+
if (CONSTANT_ADDRESS_P (y))
return 1;
diff --git a/gcc/testsuite/gcc.target/i386/pr55247-2.c
b/gcc/testsuite/gcc.target/i386/pr55247-2.c
new file mode 100644
index 000..d91b504
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr55247-2.c
@@ -0,0 +1,37 @@
+/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-options -O2 -mx32 -mtune=generic -maddress-mode=long } */
+
+typedef unsigned int uint32_t;
+typedef uint32_t Elf32_Word;
+typedef uint32_t Elf32_Addr;
+typedef struct {
+ Elf32_Word
Re: *ping* [patch, fortran] PR 30146, errors for INTENT(OUT) and INTENT(INOUT) for DO loop variables
On Sat, Nov 10, 2012 at 3:00 PM, Thomas Koenig wrote: I wrote: after the dicsussion on c.l.f, it become clear that passing a DO loop variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error. The attached patch throws an error for both cases. But should we really isse an error for INTENT(INOUT)? IMHO a warning suffices, with maybe an error only for strict (i.e. non-GNU) standard settings. I chose to issue the errors as a front-end pass because we cannot check for formal arguments during parsing (where the other checks are implemented). Regression-tested. OK for trunk? Ping ** 1.4285 ? You don't have to list do_list twice in the ChangeLog, you probably wanted one of those to be do_level ;-) + do_list = XNEWVEC(gfc_code *, do_size); Taste nit: Why not just toss do_list, do_level, and do_size around as a function argument, instead of making them global variable? Just define a struct containing them and pass it around via the data argument for gfc_code_walker should work, I think. IMHO names like do_warn and do_list are not very descriptive, if not to say confusing. do_* names are used elsewhere in the compiler for functions that perform (do) a task, whereas your do_* functions are for the Fortran DO construct. I'd prefer different names. + to an INTENt(OUT) or INTENT(INOUT) dummy variable. */ s/INTENt/INTENT/ + /* Withot a formal arglist, there is only unknown INTENT, s/Withot/Without/ + for (i=0; ido_level; i++) for (i = 0; i do_level; i++) + inside loop beginning at %L as INTENT(OUT) Extraneous space after loop. How do you handle OPTIONAL args? Ciao! Steven
[patch] PR55263
Hello, This is another ICE in pre_and_rev_post_order_compute, called from alias.c after register allocation. The problem is that purge_all_dead_edges can make basic blocks unreachable. Before my patch of r190602, alias.c handled unreachable blocks (resulting in missed disambiguations). Now that alias.c walks instructions in topological order, unreachable blocks are a no-no. But postreload-cse was never really converted to properly use and maintain the CFG, and this PR is the second example of this problem (after PR54385, which I fixed earlier this week). Fixed by calling cleanup_cfg(0) if edges were purged. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. OK if it passes? Ciao! Steven gcc/ PR middle-end/55263 * postreload.c (rest_of_handle_postreload): With non-call exceptions, if edges are purged call cleanup_cfg to remove unreachable blocks. testsuite/ PR middle-end/55263 * g++.dg/pr55263.C: New test. PR55263.diff Description: Binary data
[doc] extend.texi copy-editing, 2/N (which/that usage)
This patch continues my series of copy-edits to the GCC user
documentation. Here I've fixed a number of problems in extend.texi with
confusion between which and that, as I previously did for invoke.texi.
Committed as obvious since there are no changes to content, just grammar.
-Sandra
2012-11-10 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/extend.texi: Copy-edit to fix incorrect uses of which
and that throughout the file.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193399)
+++ gcc/doc/extend.texi (working copy)
@@ -463,7 +463,7 @@ C++ Conference Proceedings, October 17-2
A nested function can jump to a label inherited from a containing
function, provided the label is explicitly declared in the containing
function (@pxref{Local Labels}). Such a jump returns instantly to the
-containing function, exiting the nested function which did the
+containing function, exiting the nested function that did the
@code{goto} and any intermediate functions as well. Here is an example:
@smallexample
@@ -571,7 +571,7 @@ returned by @code{__builtin_apply}.
@deftypefn {Built-in Function} {} __builtin_va_arg_pack ()
This built-in function represents all anonymous arguments of an inline
-function. It can be used only in inline functions which are always
+function. It can be used only in inline functions that are always
inlined, never compiled as a separate function, such as those using
@code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
@@ -597,7 +597,7 @@ myprintf (FILE *f, const char *format, .
@deftypefn {Built-in Function} {size_t} __builtin_va_arg_pack_len ()
This built-in function returns the number of anonymous arguments of
-an inline function. It can be used only in inline functions which
+an inline function. It can be used only in inline functions that
are always inlined, never compiled as a separate function, such
as those using @code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
@@ -674,7 +674,7 @@ such a type.
@code{typeof} is often useful in conjunction with the
statements-within-expressions feature. Here is how the two together can
-be used to define a safe ``maximum'' macro that operates on any
+be used to define a safe ``maximum'' macro which operates on any
arithmetic type and evaluates each of its arguments exactly once:
@smallexample
@@ -750,7 +750,7 @@ pointers to @code{char}.
@end itemize
@emph{Compatibility Note:} In addition to @code{typeof}, GCC 2 supported
-a more limited extension which permitted one to write
+a more limited extension that permitted one to write
@smallexample
typedef @var{T} = @var{expr};
@@ -759,7 +759,7 @@ typedef @var{T} = @var{expr};
@noindent
with the effect of declaring @var{T} to have the type of the expression
@var{expr}. This extension does not work with GCC 3 (versions between
-3.0 and 3.2 crash; 3.2.1 and later give an error). Code which
+3.0 and 3.2 crash; 3.2.1 and later give an error). Code that
relies on it should be rewritten to use @code{typeof}:
@smallexample
@@ -1417,7 +1417,7 @@ space.
@cindex flexible array members
Zero-length arrays are allowed in GNU C@. They are very useful as the
-last element of a structure which is really a header for a variable-length
+last element of a structure that is really a header for a variable-length
object:
@smallexample
@@ -1877,7 +1877,7 @@ int a[6] = @{ 0, 0, 15, 0, 29, 0 @};
The index values must be constant expressions, even if the array being
initialized is automatic.
-An alternative syntax for this which has been obsolete since GCC 2.5 but
+An alternative syntax for this that has been obsolete since GCC 2.5 but
GCC still accepts is to write @samp{[@var{index}]} before the element
value, with no @samp{=}.
@@ -1919,7 +1919,7 @@ is equivalent to
struct point p = @{ xvalue, yvalue @};
@end smallexample
-Another syntax which has the same meaning, obsolete since GCC 2.5, is
+Another syntax that has the same meaning, obsolete since GCC 2.5, is
@samp{@var{fieldname}:}, as shown here:
@smallexample
@@ -2210,7 +2210,7 @@ if no optimization level is specified.
@item gnu_inline
@cindex @code{gnu_inline} function attribute
-This attribute should be used with a function which is also declared
+This attribute should be used with a function that is also declared
with the @code{inline} keyword. It directs GCC to treat the function
as if it were defined in gnu90 mode even when compiling in C99 or
gnu99 mode.
@@ -2248,7 +2248,7 @@ behavior.
@item artificial
@cindex @code{artificial} function attribute
-This attribute is useful for small inline wrappers which if possible
+This attribute is useful for small inline wrappers that if possible
should appear during debugging as a unit. Depending on the debug
info
Re: RFC: PATCH to add abi_tag attribute
The demangler change was handling the tags in the wrong place; I'm
writing them out with unqualified names, so the demangler should expect
them in the same place.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 75eef303e5494f27a6d9bbef68aaf3200978a8f1
Author: Jason Merrill ja...@redhat.com
Date: Sat Nov 10 13:10:24 2012 -0500
* cp-demangle.c (d_unqualified_name): Handle abi tags here.
(d_name): Not here.
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 86c7747..913d4bf 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -1246,17 +1246,14 @@ d_name (struct d_info *di)
switch (peek)
{
case 'N':
- dc = d_nested_name (di);
- break;
+ return d_nested_name (di);
case 'Z':
- dc = d_local_name (di);
- break;
+ return d_local_name (di);
case 'L':
case 'U':
- dc = d_unqualified_name (di);
- break;
+ return d_unqualified_name (di);
case 'S':
{
@@ -1298,7 +1295,7 @@ d_name (struct d_info *di)
d_template_args (di));
}
- break;
+ return dc;
}
default:
@@ -1313,12 +1310,8 @@ d_name (struct d_info *di)
dc = d_make_comp (di, DEMANGLE_COMPONENT_TEMPLATE, dc,
d_template_args (di));
}
- break;
+ return dc;
}
-
- if (d_peek_char (di) == 'B')
-dc = d_abi_tags (di, dc);
- return dc;
}
/* nested-name ::= N [CV-qualifiers] prefix unqualified-name E
@@ -1446,15 +1439,14 @@ d_prefix (struct d_info *di)
static struct demangle_component *
d_unqualified_name (struct d_info *di)
{
+ struct demangle_component *ret;
char peek;
peek = d_peek_char (di);
if (IS_DIGIT (peek))
-return d_source_name (di);
+ret = d_source_name (di);
else if (IS_LOWER (peek))
{
- struct demangle_component *ret;
-
ret = d_operator_name (di);
if (ret != NULL ret-type == DEMANGLE_COMPONENT_OPERATOR)
{
@@ -1463,14 +1455,11 @@ d_unqualified_name (struct d_info *di)
ret = d_make_comp (di, DEMANGLE_COMPONENT_UNARY, ret,
d_source_name (di));
}
- return ret;
}
else if (peek == 'C' || peek == 'D')
-return d_ctor_dtor_name (di);
+ret = d_ctor_dtor_name (di);
else if (peek == 'L')
{
- struct demangle_component * ret;
-
d_advance (di, 1);
ret = d_source_name (di);
@@ -1478,22 +1467,27 @@ d_unqualified_name (struct d_info *di)
return NULL;
if (! d_discriminator (di))
return NULL;
- return ret;
}
else if (peek == 'U')
{
switch (d_peek_next_char (di))
{
case 'l':
- return d_lambda (di);
+ ret = d_lambda (di);
+ break;
case 't':
- return d_unnamed_type (di);
+ ret = d_unnamed_type (di);
+ break;
default:
return NULL;
}
}
else
return NULL;
+
+ if (d_peek_char (di) == 'B')
+ret = d_abi_tags (di, ret);
+ return ret;
}
/* source-name ::= (positive length) number identifier */
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index 6b55d30..5b41b03 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -4084,6 +4084,9 @@ auto fint(int const, int)
--format=gnu-v3
_Z1gILi1EEvR1AIXT_EER1BIXscbT_EE
void g1(A1, Bstatic_castbool(1))
+--format=gnu-v3
+_ZNKSt7complexIiE4realB5cxx11Ev
+std::complexint::real[abi:cxx11]() const
#
# Ada (GNAT) tests.
#
libstdc++ PATCH to add abi tag to complex::real/imag
As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11
changes the return type of complex::real and imag, leading to a binary
incompatibility between C++98 and C++11 code if the functions are used
without inlining. This patch adds an ABI tag to the C++11 variants so
that they have different mangled names. This does not change the
exports from libstdc++.
For the map void-iterator change, I think it would make sense to just
unconditionally return an iterator; there's no binary compatibility
issue with older code that expects it to return void, the problem is
only with C++11 code calling a C++98 instantiation that returns void.
For the other cases mentioned on that page, I think either we want to
unify the two implementations (because we think they're compatible) or
add ABI tags to the C++11 implementations.
Is this patch OK for trunk? Does someone on the library team want to
look at the other cases?
commit be79353c10252bc99cac5f9d9ce045207e665238
Author: Jason Merrill ja...@redhat.com
Date: Sat Nov 10 13:10:15 2012 -0500
* include/std/complex (real, imag): Add ABI tag in C++11 mode.
diff --git a/libstdc++-v3/include/std/complex b/libstdc++-v3/include/std/complex
index f9221a8..24fa414 100644
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -141,9 +141,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus = 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag (cxx11)))
constexpr _Tp
real() { return _M_real; }
+ __attribute ((abi_tag (cxx11)))
constexpr _Tp
imag() { return _M_imag; }
#else
@@ -1061,9 +1063,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus = 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag (cxx11)))
constexpr float
real() { return __real__ _M_value; }
+ __attribute ((abi_tag (cxx11)))
constexpr float
imag() { return __imag__ _M_value; }
#else
@@ -1210,9 +1214,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus = 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag (cxx11)))
constexpr double
real() { return __real__ _M_value; }
+ __attribute ((abi_tag (cxx11)))
constexpr double
imag() { return __imag__ _M_value; }
#else
@@ -1360,9 +1366,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus = 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 387. std::complex over-encapsulated.
+ __attribute ((abi_tag (cxx11)))
constexpr long double
real() { return __real__ _M_value; }
+ __attribute ((abi_tag (cxx11)))
constexpr long double
imag() { return __imag__ _M_value; }
#else
diff --git a/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc b/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
new file mode 100644
index 000..a845466
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
@@ -0,0 +1,25 @@
+// Test that the C++11 variants of real/imag have an ABI tag
+// { dg-do compile }
+// { dg-options -std=c++11 }
+
+#include complex
+
+// { dg-final { scan-assembler _ZNKSt7complexIfE4realB5cxx11Ev } }
+float (std::complexfloat::*p1)() const = std::complexfloat::real;
+// { dg-final { scan-assembler _ZNKSt7complexIdE4realB5cxx11Ev } }
+double (std::complexdouble::*p2)() const = std::complexdouble::real;
+// { dg-final { scan-assembler _ZNKSt7complexIeE4realB5cxx11Ev } }
+long double (std::complexlong double::*p3)() const
+ = std::complexlong double::real;
+// { dg-final { scan-assembler _ZNKSt7complexIiE4realB5cxx11Ev } }
+int (std::complexint::*p4)() const = std::complexint::real;
+
+// { dg-final { scan-assembler _ZNKSt7complexIfE4imagB5cxx11Ev } }
+float (std::complexfloat::*p5)() const = std::complexfloat::imag;
+// { dg-final { scan-assembler _ZNKSt7complexIdE4imagB5cxx11Ev } }
+double (std::complexdouble::*p6)() const = std::complexdouble::imag;
+// { dg-final { scan-assembler _ZNKSt7complexIeE4imagB5cxx11Ev } }
+long double (std::complexlong double::*p7)() const
+ = std::complexlong double::imag;
+// { dg-final { scan-assembler _ZNKSt7complexIiE4imagB5cxx11Ev } }
+int (std::complexint::*p8)() const = std::complexint::imag;
[doc] extend.texi copy-editing, 3/N (hyphenated phrases)
I've checked in this patch to fix various problems with hyphenated
phrases in extend.texi. This exactly parallels similar copy edits I
made earlier this year to invoke.texi. To recap, in phrases like
64-bit types, 64-bit is a compound adjective phrase that immediately
precedes a noun and should be hyphenated. On the other hand, 64 bits
is a noun phrase and shouldn't be hyphenated. Similar rules apply to
floating-point (adjective) versus floating point (noun), etc.
-Sandra
2012-11-10 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
involving bit, byte, word, precision, and floating
modifiers.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193400)
+++ gcc/doc/extend.texi (working copy)
@@ -812,11 +812,11 @@ effects of recomputing it.
@cindex @code{__int128} data types
As an extension the integer scalar type @code{__int128} is supported for
-targets having an integer mode wide enough to hold 128-bit.
+targets having an integer mode wide enough to hold 128 bits.
Simply write @code{__int128} for a signed 128-bit integer, or
@code{unsigned __int128} for an unsigned 128-bit integer. There is no
support in GCC to express an integer constant of type @code{__int128}
-for targets having @code{long long} integer with less then 128 bit width.
+for targets having @code{long long} integer less than 128 bits wide.
@node Long Long
@section Double-Word Integers
@@ -917,8 +917,8 @@ examine and set these two fictitious var
@cindex @code{Q} floating point suffix
As an extension, the GNU C compiler supports additional floating
-types, @code{__float80} and @code{__float128} to support 80bit
-(@code{XFmode}) and 128 bit (@code{TFmode}) floating types.
+types, @code{__float80} and @code{__float128} to support 80-bit
+(@code{XFmode}) and 128-bit (@code{TFmode}) floating types.
Support for additional types includes the arithmetic operators:
add, subtract, multiply, divide; unary arithmetic operators;
relational operators; equality operators; and conversions to and from
@@ -933,7 +933,7 @@ typedef _Complex float __attribute__((mo
typedef _Complex float __attribute__((mode(XC))) _Complex80;
@end smallexample
-Not all targets support additional floating point types. @code{__float80}
+Not all targets support additional floating-point types. @code{__float80}
and @code{__float128} types are supported on i386, x86_64 and ia64 targets.
The @code{__float128} type is supported on hppa HP-UX targets.
@@ -2475,11 +2475,11 @@ referenced. On Microsoft Windows target
for functions by setting the @option{-mnop-fun-dllimport} flag.
@item eightbit_data
-@cindex eight bit data on the H8/300, H8/300H, and H8S
+@cindex eight-bit data on the H8/300, H8/300H, and H8S
Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
-variable should be placed into the eight bit data section.
+variable should be placed into the eight-bit data section.
The compiler generates more efficient code for certain operations
-on data in the eight bit data area. Note the eight bit data area is limited to
+on data in the eight-bit data area. Note the eight-bit data area is limited to
256 bytes of data.
You must use GAS and GLD from GNU binutils version 2.7 or later for
@@ -2710,8 +2710,8 @@ from the special page vector table which
bits of the subroutine's entry address. Each vector table has special
page number (18 to 255) that is used in @code{jsrs} instructions.
Jump addresses of the routines are generated by adding 0x0F (in
-case of M16C targets) or 0xFF (in case of M32C targets), to the 2
-byte addresses set in the vector table. Therefore you need to ensure
+case of M16C targets) or 0xFF (in case of M32C targets), to the
+2-byte addresses set in the vector table. Therefore you need to ensure
that all the special page vector routines should get mapped within the
address range 0x0F to 0x0F (for M16C) and 0xFF to 0xFF
(for M32C).
@@ -2811,7 +2811,7 @@ void f () __attribute__ ((interrupt (IR
Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
On ARMv7-M the interrupt type is ignored, and the attribute means the function
-may be called with a word aligned stack pointer.
+may be called with a word-aligned stack pointer.
On Epiphany targets one or more optional parameters can be added like this:
@@ -3085,7 +3085,7 @@ caller pops the stack for hidden pointer
@item ms_hook_prologue
@cindex @code{ms_hook_prologue} attribute
-On 32 bit i[34567]86-*-* targets and 64 bit x86_64-*-* targets, you can use
+On 32-bit i[34567]86-*-* targets and 64-bit x86_64-*-* targets, you can use
this function attribute to make gcc generate the hot-patching function
prologue used in Win32 API functions in Microsoft Windows XP Service Pack 2
and newer.
@@ -3422,10 +3422,10
[doc] extend.texi copy-editing, 4/N (bit-fields)
I've checked in this patch to consistently use bit-field in
extend.texi instead of bitfield or bit field. Bit-field is listed
in the GCC Coding Conventions as the preferred terminology, for
consistency with the C and C++ standards.
-Sandra
2012-11-10 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/extend.texi: Copy-edit to use bit-field consistently
instead of bitfield or bit field.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193402)
+++ gcc/doc/extend.texi (working copy)
@@ -5006,9 +5006,9 @@ Currently @option{-m[no-]ms-bitfields} i
compilers to match the native Microsoft compiler.
The Microsoft structure layout algorithm is fairly simple with the exception
-of the bitfield packing:
+of the bit-field packing:
-The padding and alignment of members of structures and whether a bit field
+The padding and alignment of members of structures and whether a bit-field
can straddle a storage-unit boundary
@enumerate
@@ -5025,19 +5025,19 @@ Every object is allocated an offset so t
offset % alignment-requirement == 0
-@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
-unit if the integral types are the same size and if the next bit field fits
+@item Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte allocation
+unit if the integral types are the same size and if the next bit-field fits
into the current allocation unit without crossing the boundary imposed by the
-common alignment requirements of the bit fields.
+common alignment requirements of the bit-fields.
@end enumerate
-Handling of zero-length bitfields:
+Handling of zero-length bit-fields:
-MSVC interprets zero-length bitfields in the following ways:
+MSVC interprets zero-length bit-fields in the following ways:
@enumerate
-@item If a zero-length bitfield is inserted between two bitfields that
-are normally coalesced, the bitfields are not coalesced.
+@item If a zero-length bit-field is inserted between two bit-fields that
+are normally coalesced, the bit-fields are not coalesced.
For example:
@@ -5050,12 +5050,12 @@ struct
@} t1;
@end smallexample
-The size of @code{t1} is 8 bytes with the zero-length bitfield. If the
-zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
+The size of @code{t1} is 8 bytes with the zero-length bit-field. If the
+zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
-@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
-alignment of the zero-length bitfield is greater than the member that follows it,
-@code{bar}, @code{bar} is aligned as the type of the zero-length bitfield.
+@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
+alignment of the zero-length bit-field is greater than the member that follows it,
+@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
For example:
@@ -5077,18 +5077,18 @@ struct
For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
Accordingly, the size of @code{t2} is 4. For @code{t3}, the zero-length
-bitfield does not affect the alignment of @code{bar} or, as a result, the size
+bit-field does not affect the alignment of @code{bar} or, as a result, the size
of the structure.
Taking this into account, it is important to note the following:
@enumerate
-@item If a zero-length bitfield follows a normal bitfield, the type of the
-zero-length bitfield may affect the alignment of the structure as whole. For
-example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
-normal bitfield, and is of type short.
+@item If a zero-length bit-field follows a normal bit-field, the type of the
+zero-length bit-field may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
+normal bit-field, and is of type short.
-@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
still affect the alignment of the structure:
@smallexample
@@ -5102,7 +5102,7 @@ struct
Here, @code{t4} takes up 4 bytes.
@end enumerate
-@item Zero-length bitfields following non-bitfield members are ignored:
+@item Zero-length bit-fields following non-bit-field members are ignored:
@smallexample
struct
@@ -5266,7 +5266,7 @@ alignment. See your linker documentatio
@item packed
This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bitfields)
+definition, specifies that each member (other than zero-width bit-fields)
of the structure or union is placed to minimize the memory required. When
attached to an @code{enum} definition, it indicates that the smallest
integral type should be used.
@@
[Obj-C++] Found a small paste-o in parser.c?
I found this suspicious looking line in cp/parser.c () while looking at
__thread and thread_local.
Look at the patterns of the if blocks above the line in question to verify.
Built and tested on x86_64-linux.
Ed
2012-11-11 Ed Smith-Rowland 3dw...@verizon.net
* parser.c (cp_parser_objc_class_ivars):
Index declspecs.locations by ds_typedef rather than ds_thread.
Index: parser.c
===
--- parser.c(revision 193380)
+++ parser.c(working copy)
@@ -24650,7 +24650,7 @@
if (decl_spec_seq_has_spec_p (declspecs, ds_typedef))
{
cp_parser_error (parser, invalid type for instance variable);
- declspecs.locations[ds_thread] = 0;
+ declspecs.locations[ds_typedef] = 0;
}
prefix_attributes = declspecs.attributes;
