Re: Building C++ with --enable-languages=c,fortran
On Saturday 06 August 2011 00:52:02 Thomas Koenig wrote: Hello world, I just noticed that C++ now appears to be built by default, even when only the C and fortran are specified. Yes, but it doesn't make much difference in practice. The only difference I saw is the debugging symbols including the full prototype (not only the function name) in the debugger. WRT to bootstrap time, as usual: it's too long. Mikael
Re: Building C++ with --enable-languages=c,fortran
On 08/06/2011 11:22 AM, Mikael Morin wrote: WRT to bootstrap time, as usual: it's too long. Well, that all depends on your (time) frame of reference, of course. In the summer months leading up to Craig Burley asking for volunteers testing g77 (the g77-alpha phase), i.e., during the summer of 1992, a bootstrap of GCC (C and C++) took 8 hours on my single 25 Mhz Motorola 68040 powered Next Station. With the new gcc, I could build a fresh f2c in minutes, and, using that combo (f2c+gcc) a recompile of our weather forecasting code took another 10 minutes. Nowadays, on a *4 year old* quad core Core 2 machine, building C, C++, Ada and Fortran takes less than 2 hours, so given that I put in 4 times as many processors, the rest of the hardware keeps up with providing me a bootstrap in 1/4th of the time it took 19 years ago, giving me twice the number of front ends plus run time libraries. I think the outlook is good :-) -- 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: libgcc: strange optimization
On 08/04/2011 01:10 PM, Andrew Haley wrote: It's the sort of thing that gets done in threaded interpreters, where you really need to keep a few pointers in registers and the interpreter itself is a very long function. gcc has always done a dreadful job of register allocation in such cases. Sure, but what I have seen people use global register variables for this (which means they get taken away from the register allocator). Not always though, and the x86 has so few registers that using a global register variable is very problematic. I suppose you could compile the threaded interpreter in a file of its own, but I'm not sure that has quite the same semantics as local register variables. Indeed, local register variables give almost the same benefit as globals with half the burden. The idea is that you don't care about the exact register that holds the contents but, by specifying a callee-save register, GCC will use those instead of memory across calls. This reduces _a lot_ the number of spills. The problem is that people who care about this stuff very much don't always read...@gcc.gnu.org so won't be heard. But in their own world (LISP, Forth) nice features like register variables and labels as values have led to gcc being the preferred compiler for this kind of work. /me raises hands. For GNU Smalltalk, using #if defined(__i386__) # define __DECL_REG1 __asm(%esi) # define __DECL_REG2 __asm(%edi) # define __DECL_REG3 /* no more caller-save regs if PIC is in use! */ #endif #if defined(__x86_64__) # define __DECL_REG1 __asm(%r12) # define __DECL_REG2 __asm(%r13) # define __DECL_REG3 __asm(%rbx) #endif ... register unsigned char *ip __DECL_REG1; register OOP * sp __DECL_REG2; register intptr_t arg __DECL_REG3; improves performance by up to 20% if I remember correctly. I can benchmark it if desired. It does not come for free, in some cases the register allocator does some stupid things due to the hard register declaration. But it gets much better code overall, so who cares about the microoptimization. Of course, if the register allocator did the right thing, or if I could use simply unsigned char *ip __attribute__(__do_not_spill_me__(20))); OOP *sp __attribute__(__do_not_spill_me__(10))); intptr_t arg __attrbite__(__do_not_spill_me__(0))); that would be just fine. Paolo
Re: Building C++ with --enable-languages=c,fortran
On Sat, Aug 06, 2011 at 03:16:43PM +0200, Toon Moene wrote: On 08/06/2011 11:22 AM, Mikael Morin wrote: WRT to bootstrap time, as usual: it's too long. Well, that all depends on your (time) frame of reference, of course. In the summer months leading up to Craig Burley asking for volunteers testing g77 (the g77-alpha phase), i.e., during the summer of 1992, a bootstrap of GCC (C and C++) took 8 hours on my single 25 Mhz Motorola 68040 powered Next Station. With the new gcc, I could build a fresh f2c in minutes, and, using that combo (f2c+gcc) a recompile of our weather forecasting code took another 10 minutes. Nowadays, on a *4 year old* quad core Core 2 machine, building C, C++, Ada and Fortran takes less than 2 hours, so given that I put in 4 times as many processors, the rest of the hardware keeps up with providing me a bootstrap in 1/4th of the time it took 19 years ago, giving me twice the number of front ends plus run time libraries. I think the outlook is good :-) You left out the crucial hardware spec. How much memory did you have 19 years ago compared to the system today? My experience with g++ is that it will consume more memory than gcc. -- Steve
Re: autogen version testing in fixincludes/genfixes
On Wed, 8 Jun 2011, Andreas Schwab wrote: Basile Starynkevitch bas...@starynkevitch.net writes: And I also believe that the minuscule patch I am proposing in http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html should work on your system too. Could you try it please? That's not the point. The point is, if you patch, you should do it right. Hello, so what's the right way to do it? (the number of people using 5.12 is increasing, we have to fix it) 1) not test autogen at all. It will fail if it has to fail. Besides, nobody has autogen 4.* anymore. 2) instead of grepping Ver. 5., grep for 5. or GNU, or grep -v for [0-4]. 3) something else. -- Marc Glisse
PING: PATCH: Use int64 for x86 options
Ping. AVX2 support depends on this patch. Thanks. On Thu, Aug 4, 2011 at 5:49 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Aug 4, 2011 at 4:44 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Thu, 4 Aug 2011, H.J. Lu wrote: Here is the updated patch to get proper HOST_WIDE_INT bits and 1 through a new file, opt-gen.c. OK for trunk? Using another generator program like this can't be the best approach (apart from anything else, when built for the build system hwint.h should reflect the build system types not the host system types; cf. http://gcc.gnu.org/ml/gcc/2010-08/msg00111.html where I suspected that sort of host/build confusion of causing a reported build failure). You want opth-gen.awk to know the number of bits to give errors. Note that the errors are given by generating #error into the output file. It's easy enough to generate #if conditions into the file that compare with HOST_BITS_PER_WIDE_INT. You want opth-gen.awk to know whether to use 1LL as the shifted constant. You can easily enough make hwint.h contain a HOST_WIDE_INT_1 macro, defined to 1L or 1LL as appropriate. Here is the updated patch. OK for trunk? Small update. Replace 1LL with HOST_WIDE_INT_1 in PTA_XXX. OK for trunk? Thanks. -- H.J. --- 2011-08-04 H.J. Lu hongjiu...@intel.com Igor Zamyatin igor.zamya...@intel.com * hwint.h (HOST_WIDE_INT_1): New. * opt-functions.awk (switch_bit_fields): Initialize the host_wide_int field. (host_wide_int_var_name): New. (var_type_struct): Check and return HOST_WIDE_INT. * opt-read.awk: Handle HOST_WIDE_INT for Variable. * optc-save-gen.awk: Support HOST_WIDE_INT on var_target_other. * opth-gen.awk: Use HOST_WIDE_INT_1 on HOST_WIDE_INT. Properly check masks for HOST_WIDE_INT. * opts-common.c (set_option): Support HOST_WIDE_INT Flag_var. * opts.h (cl_option): Add cl_host_wide_int. Change var_value to HOST_WIDE_INT. * config/i386/i386-c.c (ix86_target_macros_internal): Replace int with HOST_WIDE_INT for isa_flag. (ix86_pragma_target_parse): Replace int with HOST_WIDE_INT for isa variables. * config/i386/i386.c (ix86_target_string): Replace int with HOST_WIDE_INT for isa. Use HOST_WIDE_INT_PRINT to print isa. (ix86_target_opts): Replace int with HOST_WIDE_INT on mask. (pta_flags): Removed. (PTA_XXX): Redefined as (HOST_WIDE_INT_1 X). (pta): Use HOST_WIDE_INT on flags. (builtin_isa): Use HOST_WIDE_INT on isa. (ix86_add_new_builtins): Likewise. (def_builtin): Use HOST_WIDE_INT on mask. (def_builtin_const): Likewise. (builtin_description): Likewise. * config/i386/i386.opt (ix86_isa_flags): Replace int with HOST_WIDE_INT. (ix86_isa_flags_explicit): Likewise. (x_ix86_isa_flags_explicit): Likewise. -- H.J.
Re: Building C++ with --enable-languages=c,fortran
On 08/06/2011 05:14 PM, Steve Kargl wrote: You left out the crucial hardware spec. How much memory did you have 19 years ago compared to the system today? My experience with g++ is that it will consume more memory than gcc. That might be true - I have never experienced memory shortage *building* C and C++ in 1992 - I had 16 Mbyte of RAM at that time. Nowadays I have 4 Gbyte of RAM, but still *bootstrapping* doesn't seem to be a problem (certain parts of the weather forecasting system these days stretch the virtual memory system, but with 4 Gbyte RAM and 11 Gbyte SWAP I still survive). -- 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
__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?
Hello,
This isn't really a compiler bug, but it's something which the manual
doesn't describe too well so I thought I would point this out.
This page of the manual:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros
says this:
You should use these macros for testing like this:
/* Test for a little-endian machine */
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
... except you shouldn't !
To test for a little-endian machine you do this;
#include endian.h
#if __BYTE_ORDER == __LITTLE_ENDIAN
I hope this is helpful. Keep up the great work!
Regards,
Chris
My test:
#include iostream
int main()
{
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
std::cout small end first\n;
#endif
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
std::cout big end first\n;
#endif
return 0;
}
Output:
small end first
big end first
gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib
--disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/python
--enable-checking=release --enable-java-awt=gtk --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5
p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)
--
They say great science is built on the shoulders of giants - not
here. At Aperture we do all our science from scratch; no hand
holding. - Cave Johnson, CEO Aperture Science.
Follow me on twitter: @zeonglow
gcc-4.7-20110806 is now available
Snapshot gcc-4.7-20110806 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110806/ 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/trunk revision 177537 You'll find: gcc-4.7-20110806.tar.bz2 Complete GCC MD5=6931db45cfb0e11719b2839fdfa0760b SHA1=f5e0eed3e326cbd386d53f24aeb54501abee7f1a Diffs from 4.7-20110730 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: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?
On Sat, Aug 6, 2011 at 5:40 PM, Christopher Huang-Leaver zeong...@googlemail.com wrote: Output: small end first big end first gcc -v gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) I got the same result with g++-4.4 (4.4.6), g++-4.5 (4.5.3) on Debian testing. But with g++-4.6, I got small end first on my x86_64-linux-gnu machine. I think it's a bug, but it has been fixed in g++-4.6. Regards, Jie
Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?
On 6 August 2011 22:40, Christopher Huang-Leaver wrote: Hello, This isn't really a compiler bug, but it's something which the manual doesn't describe too well so I thought I would point this out. This page of the manual: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros That documentation refers to the latest sources in GCC trunk, not to GCC 4.4
Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?
On Sat, Aug 6, 2011 at 9:35 PM, Jonathan Wakely jwakely@gmail.com wrote: On 6 August 2011 22:40, Christopher Huang-Leaver wrote: Hello, This isn't really a compiler bug, but it's something which the manual doesn't describe too well so I thought I would point this out. This page of the manual: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros That documentation refers to the latest sources in GCC trunk, not to GCC 4.4 Ha, so it's not a bug. It's a new feature, which doesn't exist before 4.6. Jie
[Bug target/49688] [alpha]: Many execution test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49688 --- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 06:29:18 UTC --- (In reply to comment #20) http://sourceware.org/ml/binutils/2011-08/msg00052.html Works ok on native alpha [1]. There are two remaining problems, an assert in as, as reported in [2] FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition2.C execution,-Os -fprofile-use /tmp/cccx2jTq.s: Assembler messages:^M /tmp/cccx2jTq.s:122: Error: invalid operands (.text.unlikely and .text.startup sections) for `-'^M /home/uros/bin/as: BFD (GNU Binutils) 2.21.52.20110623 assertion fail elf.c:2826^M g++: internal compiler error: Segmentation fault (program as)^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1 and FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O0 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O0 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O1 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O1 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O2 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O2 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-Os -fprofile-use /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/tree-prof/partition1.C: In function 'void foo()':^M /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/tree-prof/partition1.C:46:1: internal compiler error: in reload_combine_note_use, at postreload.c:1538^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M [1] http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00614.html [2] http://sourceware.org/ml/binutils/2011-08/msg00056.html
[Bug rtl-optimization/50001] New: [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 Summary: [alpha]: ICE in reload_combine_note_use, at postreload.c:1538 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ubiz...@gmail.com Target: alphaev68-unknown-linux-gnu Created attachment 24930 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24930 Profiler file Currently g++.dg/tree-prof/partition1.C ICEs during -fprofile-use compile using attached gcda file: FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O0 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O0 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O1 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O1 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O2 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O2 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-Os -fprofile-use ~/gcc-build-alpha/gcc/cc1plus -O2 -freorder-blocks-and-partition -fprofile-use -w -quiet partition1.C partition1.C: In function ‘void foo()’: partition1.C:46:1: internal compiler error: in reload_combine_note_use, at postreload.c:1538 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) up #1 0x0092a808 in reload_combine_note_use (xp=optimized out, insn=0x71a197e0, ruid=3, containing_mem=optimized out) at ../../gcc-svn/trunk/gcc/postreload.c:1538 1538gcc_assert (regno FIRST_PSEUDO_REGISTER); (gdb) bt #0 fancy_abort (file=0xdb5b58 ../../gcc-svn/trunk/gcc/postreload.c, line=1538, function=0xdb6050 reload_combine_note_use) at ../../gcc-svn/trunk/gcc/diagnostic.c:892 #1 0x0092a808 in reload_combine_note_use (xp=optimized out, insn=0x71a197e0, ruid=3, containing_mem=optimized out) at ../../gcc-svn/trunk/gcc/postreload.c:1538 #2 0x0092a5e7 in reload_combine_note_use (xp=optimized out, insn=0x71a197e0, ruid=3, containing_mem=0x71a17288) at ../../gcc-svn/trunk/gcc/postreload.c:1600 #3 0x0092a5a5 in reload_combine_note_use (xp=optimized out, insn=0x71a197e0, ruid=3, containing_mem=0x0) at ../../gcc-svn/trunk/gcc/postreload.c:1604 #4 0x0092bb3f in reload_combine () at ../../gcc-svn/trunk/gcc/postreload.c:1384 #5 0x0092ca1e in reload_cse_regs (first=0x719e06c0) at ../../gcc-svn/trunk/gcc/postreload.c:72 The problem can be triggered with a c++ crosscompiler to --target=alphaev68-pc-linux-gnu.
[Bug target/49688] [alpha]: Many execution test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49688 --- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 07:21:06 UTC --- (In reply to comment #21) There are two remaining problems, an assert in as, as reported in [2] FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition2.C execution,-Os -fprofile-use This is PR 49972, reportedly fixed in binutils [1]. FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O0 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O0 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O1 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O1 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O2 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O2 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-Os -fprofile-use This is now reported as PR 50001. [1] http://sourceware.org/ml/binutils/2011-08/msg00057.html
[Bug target/49688] [alpha]: Many execution test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49688 --- Comment #23 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 07:24:41 UTC --- (In reply to comment #22) This is PR 49972, reportedly fixed in binutils [1]. Er, the ice in gas with invalid .gcc_except_table is fixed in binutis.
[Bug target/49614] FAIL: gcc.dg/vmx/gcc-bug-i.c -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49614
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.08.06 07:45:19
CC||iains at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Iain Sandoe iains at gcc dot gnu.org 2011-08-06 07:45:19
UTC ---
well, what the warning is saying is that it wants the function to be declared
inline or it's not happy to accept always_inline.
I guess the language lawyers could decide that __attribute__
((always_inline)) implies inline - in which case the parsing of the
attribute needs to set DECL_DECLARED_INLINE_P.
===
As things stand, the problem can be resolved by declaring the function inline -
like so;
Index: gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c
===
--- gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c(revision 177459)
+++ gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c(working copy)
@@ -13,7 +13,7 @@
#define DO_INLINE __attribute__ ((always_inline))
#define DONT_INLINE __attribute__ ((noinline))
-static DO_INLINE int inline_me(vector signed short data)
+static inline DO_INLINE int inline_me(vector signed short data)
{
union {vector signed short v; signed short s[8];} u;
u.v = data;
[Bug libobjc/50002] New: class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002
Summary: class_replaceMethod does not work on class methods
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Reported by Jonathan Schleifer --
#include stdio.h
#include assert.h
#import objc/Object.h
#import objc/runtime.h
id
alloc(Class self, SEL _cmd)
{
puts(Foo!);
return nil;
}
int
main()
{
Method method = class_getClassMethod([Object class], @selector(alloc));
assert(method != NULL);
/* INCOMPATIBLE to Apple! class_pointer should be isa!! */
class_replaceMethod([Object class]-class_pointer, @selector(alloc),
(IMP)alloc, method_getTypeEncoding(method));
[Object alloc];
return 0;
}
If you change Object to NSObject and class_pointer to isa, it works on OS X.
Thanks
[Bug libobjc/50003] New: -[Protocol respondsTo:] does not work with Clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50003
Summary: -[Protocol respondsTo:] does not work with Clang
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Jonathan Schleifer reports --
Hi!
When using -[Protocol respondsTo:] in the new GNU runtime, it seems to return
NO, even if the object conforms to the protocol. The code I use is this:
+ (BOOL)conformsToProtocol: (Protocol*)protocol
{
Class c;
struct objc_protocol_list *pl;
size_t i;
for (c = self; c != Nil; c = class_get_super_class(c))
for (pl = c-protocols; pl != NULL; pl = pl-next)
for (i = 0; i pl-count; i++)
if ([pl-list[i] conformsTo: protocol])
return YES;
return NO;
}
It works when just using gcc 4.6.1, and it seems to work with older versions of
the GNU runtime.
Thanks
PS: For clarity, Jonathan uses the GCC Objective-C runtime with other
Objective-C compilers as well, such as clang.
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with internal compiler error: in perform_member_init, at cp/init.c:530
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-06 08:54:17 UTC --- Fixed for 4.6.2 and 4.7.0.
[Bug fortran/50004] New: [4.7 Regression] ICE in c_ptr_tests_16.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50004 Summary: [4.7 Regression] ICE in c_ptr_tests_16.f90 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: tkoe...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org The recent commit to fix PR 37211 has led to a regression in c_ptr_tests_16.f90. Am looking into this.
[Bug fortran/50004] [4.7 Regression] ICE in c_ptr_tests_16.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50004 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.08.06 09:19:12 Ever Confirmed|0 |1
[Bug rtl-optimization/49994] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -Os -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49994 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-08-06 09:23:43 UTC --- Created attachment 24931 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24931 more real-life testcase $ gcc -O -fno-omit-frame-pointer -fschedule-insns2 -fsched2-use-superblocks testcase.c testcase.c: In function 'bar': testcase.c:7:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2234 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This ICE occurs several times when running the libstdc++ testsuite with -fno-omit-frame-pointer -fsched2-use-superblocks in RUNTESTFLAGS.
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 09:49:33 UTC --- Author: nicola Date: Sat Aug 6 09:49:30 2011 New Revision: 177505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177505 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * class.c (class_getSuperclass): Return the superclass if the class is in construction. * objc/runtime.h (class_getSuperclass): Updated documentation. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * objc.dg/gnu-api-2-class.m (main): Test class_getSuperclass() with classes that are in construction. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c trunk/libobjc/objc/runtime.h
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 11:10:32
UTC ---
Compilation dies on:
#1 0x0092a84b in reload_combine_note_use (xp=optimized out,
insn=0x71a197e0, ruid=3, containing_mem=optimized out)
at ../../gcc-svn/trunk/gcc/postreload.c:1543
1543gcc_assert (regno FIRST_PSEUDO_REGISTER);
(gdb) p debug_rtx (insn)
(insn 262 266 263 51 (unspec_volatile [
(mem/c:DI (plus:DI (reg/f:DI 65 virtual-stack-vars)
(const_int 16 [0x10])) [0 S8 A64])
] UNSPECV_EHR) 278 {*exception_receiver_2}
(nil))
$1 = void
The function does not like virtual stack vars.
[Bug middle-end/49990] Regression: Bootstrap failure for x86_64-*-mingw32 in libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49990 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2011-08-06 11:14:25 UTC --- I can confirm that suggested patch fixes boolstrap issue. The testsuite run has also no new regression for alloca related cases.
[Bug other/44080] Call GNU ld with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44080 --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2011-08-06 12:06:20 UTC --- Created attachment 24932 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24932 patch spec Testing for -Ox x=3 within the specs is ugly (see the patch) but seems to work, thanks to the special treatment for -O* options (all but the last one are ignored), and seems preferable to doing it in the code. I don't know if we also want to do something for -Os. Bootstrapped with -O3.
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.08.06 12:13:49 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 12:13:49 UTC --- Created attachment 24933 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24933 Patch in testing. Patch that implements TARGET_INSTANTIATE_DECLS for alpha.
[Bug fortran/50004] [4.7 Regression] ICE in c_ptr_tests_16.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50004 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-06 12:52:35 UTC --- I have an (obvious) patch that I plan to commit this evening.
[Bug fortran/37211] TRANSFER to characters: Size checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37211 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-08-06 13:40:25 UTC --- On Linux/x86, I got FAIL: gfortran.dg/c_ptr_tests_16.f90 -O (test for excess errors) Excess errors: /export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90:58:9: Error: Can't convert INTEGER(4) to TYPE(c_funptr) at (1) /export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90:49:11: Error: Can't convert INTEGER(4) to TYPE(c_ptr) at (1)
[Bug fortran/37211] TRANSFER to characters: Size checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37211 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2011-08-06 13:46:58 UTC --- (In reply to comment #5) On Linux/x86, I got FAIL: gfortran.dg/c_ptr_tests_16.f90 -O (test for excess errors) Excess errors: /export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90:58:9: Error: Can't convert INTEGER(4) to TYPE(c_funptr) at (1) /export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90:49:11: Error: Can't convert INTEGER(4) to TYPE(c_ptr) at (1) Tracked in PR50004.
[Bug c++/49912] ICE from -freorder-blocks-and-partition : verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49912 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-08-06 14:03:50 UTC --- Created attachment 24934 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24934 reduced testcase It is reduced from libstdc++-v3/testsuite/util/testsuite_abi.cc, not from the original testcase in this PR. Compiler output: $ gcc -O -freorder-blocks-and-partition testcase.C testcase.C: In member function 'void vectoranonymous ::_M_insert_aux(const string) [with int anonymous = 0]': testcase.C:39:1: error: wrong number of branch edges after unconditional jump 7 testcase.C:39:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. 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-177503-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/smatz/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-177503-lto-fortran-checking-yes-rtl-df/ --with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl/ --disable-ppl-version-check Thread model: posix gcc version 4.7.0 20110806 (experimental) (GCC) Tested revisions (x86_64-unknown-linux-gnu): r177503 - crash r177422 - crash r173150 - OK
[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:05:43 UTC --- Author: hjl Date: Sat Aug 6 14:05:39 2011 New Revision: 177509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177509 Log: Add testcases for PRs 48084/49504/49860. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/48084 * gcc.target/i386/pr48084-1.c: New. * gcc.target/i386/pr48084-2.c: Likewise. * gcc.target/i386/pr48084-3.c: Likewise. * gcc.target/i386/pr48084-4.c: Likewise. * gcc.target/i386/pr48084-5.c: Likewise. PR rtl-optimization/49504 * gcc.target/i386/pr49504.c: New. PR target/49860 * gcc.dg/pr49860.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr49860.c trunk/gcc/testsuite/gcc.target/i386/pr48084-1.c trunk/gcc/testsuite/gcc.target/i386/pr48084-2.c trunk/gcc/testsuite/gcc.target/i386/pr48084-3.c trunk/gcc/testsuite/gcc.target/i386/pr48084-4.c trunk/gcc/testsuite/gcc.target/i386/pr48084-5.c trunk/gcc/testsuite/gcc.target/i386/pr49504.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49860 --- Comment #13 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:05:43 UTC --- Author: hjl Date: Sat Aug 6 14:05:39 2011 New Revision: 177509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177509 Log: Add testcases for PRs 48084/49504/49860. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/48084 * gcc.target/i386/pr48084-1.c: New. * gcc.target/i386/pr48084-2.c: Likewise. * gcc.target/i386/pr48084-3.c: Likewise. * gcc.target/i386/pr48084-4.c: Likewise. * gcc.target/i386/pr48084-5.c: Likewise. PR rtl-optimization/49504 * gcc.target/i386/pr49504.c: New. PR target/49860 * gcc.dg/pr49860.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr49860.c trunk/gcc/testsuite/gcc.target/i386/pr48084-1.c trunk/gcc/testsuite/gcc.target/i386/pr48084-2.c trunk/gcc/testsuite/gcc.target/i386/pr48084-3.c trunk/gcc/testsuite/gcc.target/i386/pr48084-4.c trunk/gcc/testsuite/gcc.target/i386/pr48084-5.c trunk/gcc/testsuite/gcc.target/i386/pr49504.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/48084] [x32] internal compiler error: in copy_to_mode_reg, at explow.c:630
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48084 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:05:43 UTC --- Author: hjl Date: Sat Aug 6 14:05:39 2011 New Revision: 177509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177509 Log: Add testcases for PRs 48084/49504/49860. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/48084 * gcc.target/i386/pr48084-1.c: New. * gcc.target/i386/pr48084-2.c: Likewise. * gcc.target/i386/pr48084-3.c: Likewise. * gcc.target/i386/pr48084-4.c: Likewise. * gcc.target/i386/pr48084-5.c: Likewise. PR rtl-optimization/49504 * gcc.target/i386/pr49504.c: New. PR target/49860 * gcc.dg/pr49860.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr49860.c trunk/gcc/testsuite/gcc.target/i386/pr48084-1.c trunk/gcc/testsuite/gcc.target/i386/pr48084-2.c trunk/gcc/testsuite/gcc.target/i386/pr48084-3.c trunk/gcc/testsuite/gcc.target/i386/pr48084-4.c trunk/gcc/testsuite/gcc.target/i386/pr48084-5.c trunk/gcc/testsuite/gcc.target/i386/pr49504.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:20:13 UTC --- Author: nicola Date: Sat Aug 6 14:20:09 2011 New Revision: 177510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177510 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * class.c (__objc_update_classes_with_methods): Iterate over meta classes as well as normal classes when refreshing the method implementations. This fixes replacing class methods. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com * class.c (class_getSuperclass): Fixed to work with meta classes still in construction too. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * objc.dg/gnu-api-2-class.m: Updated comments. * obj-c++.dg/gnu-api-2-class.mm: Likewise. * objc.dg/gnu-api-2-class-meta.m: New test. * obj-c++.dg/gnu-api-2-class-meta.mm: Likewise. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * obj-c++.dg/gnu-api-2-class.mm (main): Test class_getSuperclass() with classes that are in construction. Added: trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class-meta.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class-meta.m Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:20:13 UTC --- Author: nicola Date: Sat Aug 6 14:20:09 2011 New Revision: 177510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177510 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * class.c (__objc_update_classes_with_methods): Iterate over meta classes as well as normal classes when refreshing the method implementations. This fixes replacing class methods. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com * class.c (class_getSuperclass): Fixed to work with meta classes still in construction too. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * objc.dg/gnu-api-2-class.m: Updated comments. * obj-c++.dg/gnu-api-2-class.mm: Likewise. * objc.dg/gnu-api-2-class-meta.m: New test. * obj-c++.dg/gnu-api-2-class-meta.mm: Likewise. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * obj-c++.dg/gnu-api-2-class.mm (main): Test class_getSuperclass() with classes that are in construction. Added: trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class-meta.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class-meta.m Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:21:29 UTC --- Confirmed, then fixed in trunk (which will be 4.7.x). Thanks
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:22:16 UTC --- Confirmed, and fixed in trunk (will go into 4.7). Thanks
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #20 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:26:02 UTC --- Author: hjl Date: Sat Aug 6 14:25:58 2011 New Revision: 177511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177511 Log: Add testcases for PRs 47766/47715. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/47766 * gcc.dg/pr47766.c: New. PR target/47715 * gcc.dg/tls/pr47715-1.c: New. * gcc.dg/tls/pr47715-2.c: Likewise. * gcc.dg/tls/pr47715-3.c: Likewise. * gcc.dg/tls/pr47715-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr47766.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-1.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-2.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-3.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-4.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47766] [x32] -fstack-protector doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47766 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:26:01 UTC --- Author: hjl Date: Sat Aug 6 14:25:58 2011 New Revision: 177511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177511 Log: Add testcases for PRs 47766/47715. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/47766 * gcc.dg/pr47766.c: New. PR target/47715 * gcc.dg/tls/pr47715-1.c: New. * gcc.dg/tls/pr47715-2.c: Likewise. * gcc.dg/tls/pr47715-3.c: Likewise. * gcc.dg/tls/pr47715-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr47766.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-1.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-2.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-3.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-4.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47446] [x32] .quad instead of .long is used for address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:36:55 UTC --- Author: hjl Date: Sat Aug 6 14:36:52 2011 New Revision: 177512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177512 Log: Add testcases for PRs 47449/47446. 2011-08-06 H.J. Lu hongjiu...@intel.com PR middle-end/47449 * gcc.target/i386/pr47449.c: New. PR target/47446 * gcc.dg/pr47446-1.c: New. * gcc.dg/pr47446-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr47446-1.c trunk/gcc/testsuite/gcc.dg/pr47446-2.c trunk/gcc/testsuite/gcc.target/i386/pr47449.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/47449] [x32] can’t find a register in class ‘DIREG’ while reloading ‘asm’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47449 --- Comment #15 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:36:55 UTC --- Author: hjl Date: Sat Aug 6 14:36:52 2011 New Revision: 177512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177512 Log: Add testcases for PRs 47449/47446. 2011-08-06 H.J. Lu hongjiu...@intel.com PR middle-end/47449 * gcc.target/i386/pr47449.c: New. PR target/47446 * gcc.dg/pr47446-1.c: New. * gcc.dg/pr47446-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr47446-1.c trunk/gcc/testsuite/gcc.dg/pr47446-2.c trunk/gcc/testsuite/gcc.target/i386/pr47449.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #21 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:50:12 UTC --- Author: hjl Date: Sat Aug 6 14:50:05 2011 New Revision: 177513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177513 Log: Add testcases for PRs 47727/47372/47715. 2011-08-06 H.J. Lu hongjiu...@intel.com PR middle-end/47727 * gcc.dg/pr47727.c: New. PR target/47372 * gcc.dg/pr47372-1.c: New. * gcc.dg/pr47372-2.c: Likewise. PR target/47715 * gcc.dg/tls/pr47715-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr47372-1.c trunk/gcc/testsuite/gcc.dg/pr47372-2.c trunk/gcc/testsuite/gcc.dg/pr47727.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-5.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47372] [x32] internal compiler error: in simplify_subreg, at simplify-rtx.c:5222
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47372 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:50:12 UTC --- Author: hjl Date: Sat Aug 6 14:50:05 2011 New Revision: 177513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177513 Log: Add testcases for PRs 47727/47372/47715. 2011-08-06 H.J. Lu hongjiu...@intel.com PR middle-end/47727 * gcc.dg/pr47727.c: New. PR target/47372 * gcc.dg/pr47372-1.c: New. * gcc.dg/pr47372-2.c: Likewise. PR target/47715 * gcc.dg/tls/pr47715-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr47372-1.c trunk/gcc/testsuite/gcc.dg/pr47372-2.c trunk/gcc/testsuite/gcc.dg/pr47727.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-5.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47727 --- Comment #12 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:50:12 UTC --- Author: hjl Date: Sat Aug 6 14:50:05 2011 New Revision: 177513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177513 Log: Add testcases for PRs 47727/47372/47715. 2011-08-06 H.J. Lu hongjiu...@intel.com PR middle-end/47727 * gcc.dg/pr47727.c: New. PR target/47372 * gcc.dg/pr47372-1.c: New. * gcc.dg/pr47372-2.c: Likewise. PR target/47715 * gcc.dg/tls/pr47715-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr47372-1.c trunk/gcc/testsuite/gcc.dg/pr47372-2.c trunk/gcc/testsuite/gcc.dg/pr47727.c trunk/gcc/testsuite/gcc.dg/tls/pr47715-5.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47381] [x32] internal compiler error: in gen_lowpart_general, at rtlhooks.c:59
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47381 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-06 14:57:55 UTC --- Author: hjl Date: Sat Aug 6 14:57:52 2011 New Revision: 177514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177514 Log: Add testcases for PR 47381. 2011-08-06 H.J. Lu hongjiu...@intel.com PR target/47381 * gcc.dg/pr47381-1.c: New. * gcc.dg/pr47381-2.c: Likewise. * gcc.target/i386/pr47381.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr47381-1.c trunk/gcc/testsuite/gcc.dg/pr47381-2.c trunk/gcc/testsuite/gcc.target/i386/pr47381.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50005] New: [4.7 Regression] ipa-inline-analysis.c:1876:41: error: comparison between signed an d unsigned integer expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50005 Summary: [4.7 Regression] ipa-inline-analysis.c:1876:41: error: comparison between signed an d unsigned integer expressions Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: hubi...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.00 Target: hppa2.0w-hp-hpux11.00 Build: hppa2.0w-hp-hpux11.00 /xxx/gnu/gcc/objdir/./prev-gcc/xgcc -B/xxx/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu /gcc/gcc-4.7/hppa2.0w-hp-hpux11.00/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux1 1.00/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.00/lib/ -isystem /opt/gnu/gc c/gcc-4.7/hppa2.0w-hp-hpux11.00/include -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-h p-hpux11.00/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcas t-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -peda ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-s tyle-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../g cc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu /gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumbe r/dpd -I../libdecnumber../../gcc/gcc/ipa-inline-analysis.c -o ipa-inline-ana lysis.o ../../gcc/gcc/ipa-inline-analysis.c: In function 'remap_predicate': ../../gcc/gcc/ipa-inline-analysis.c:1876:41: error: comparison between signed an d unsigned integer expressions [-Werror=sign-compare] cc1: all warnings being treated as errors
[Bug debug/50006] New: [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50006 Summary: [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: r...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc -4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/lib / -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/ gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include-c -g -O2 -fPIC -frandom-seed= fixed-seed -W -Wall -gnatpg s-os_lib.adb -o s-os_lib.o +===GNAT BUG DETECTED==+ | 4.7.0 20110805 (experimental) [trunk revision 177484] (hppa2.0w-hp-hpux11.11) GCC error:| | in connect_traces, at dwarf2cfi.c:2677 | | Error detected around s-os_lib.adb:897:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug fortran/50004] [4.7 Regression] ICE in c_ptr_tests_16.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50004 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-06 15:19:48 UTC --- Author: tkoenig Date: Sat Aug 6 15:19:45 2011 New Revision: 177527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177527 Log: 2011-08-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/50004 * target-memory.c (gfc_target_expr-size): Don't clobber typespec for derived types. * simplify.c (gfc_simplify_transfer): Don't calculate source_size twice. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c
[Bug fortran/50004] [4.7 Regression] ICE in c_ptr_tests_16.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50004 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-06 15:26:55 UTC --- Fixed, closing.
[Bug c/44938] Variable origtypes in c-parser.c accessed uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2011-08-06 15:47:21 UTC --- This breaks a -O3 bootstrap (-Werror turns the warning into an error). The code looks like: VEC(tree,gc) *origtypes; ... if(...) exprlist = NULL; else exprlist = c_parser_expr_list (parser, true, false, origtypes); ... expr.value = build_function_call_vec (op_loc, expr.value, exprlist, origtypes); So g++ is right to warn (even if origtypes is probably unused in that case).
[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-08-06 15:58:47 UTC --- So, Eric - are you still objecting to make VRP and the middle-end aligned by ignoring TYPE_MIN/MAX_VALUE in VRP? Just to give a bit of context to the reader: this problem bit the Ada compiler since VRP had been introduced in 2004. At the time, the consensus was that the Ada compiler was lying to the middle-end, because objects of type T could have values that are outside [TYPE_MIN_VALUE:TYPE_MAX_VALUE] in some cases and this breaks an invariant of the middle-end. So we changed the Ada compiler in 2009. If it appears that the previous consensus was short-sighted and should now be reversed, fine with me, but please document what TYPE_MIN_VALUE/TYPE_MAX_VALUE mean under the new one. And if they don't mean anything, then remove them.
[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-08-06 16:08:16 UTC --- So the issue here is that enum types with non-canonical TYPE_MIN/MAX_VALUE leak from storage representation (union StateRemat) via SRA as register variables into the IL. Is that something that cannot happen for Ada because it is also careful to not use such types in storage representations? Yes, I think so, only index types of arrays have non-canonical bounds now.
[Bug lto/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-06 16:29:58 UTC --- On x86_64-apple-darwin10 I get the same bootstrap failure: ... mv -f Tlto-wrapper lto-wrapper gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/opt/sw64/lib -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o collect2: ld returned 1 exit status make[3]: *** [gengtype] Error 1 make[3]: *** Waiting for unfinished jobs rm gcov.pod gfdl.pod cpp.pod fsf-funding.pod gcc.pod make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 with the following configure ../p_work/configure --prefix=/opt/gcc/gcc4.7p --enable-languages=c,c++,lto,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --enable-checking=release --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto but not with ../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto Apparently the key is --enable-checking=something.
[Bug rtl-optimization/49994] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49994 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.08.06 17:10:29 CC||rth at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-08-06 17:10:29 UTC --- It is caused by revision 176705: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00973.html
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 --- Comment #3 from uros at gcc dot gnu.org 2011-08-06 18:39:23 UTC --- Author: uros Date: Sat Aug 6 18:39:19 2011 New Revision: 177531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177531 Log: PR target/50001 * config/alpha/alpha.c (alpha_instantiate_decls): New function. (TARGET_INSTANTIATE_DECLS): New define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 --- Comment #4 from uros at gcc dot gnu.org 2011-08-06 18:41:16 UTC --- Author: uros Date: Sat Aug 6 18:41:14 2011 New Revision: 177532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177532 Log: PR target/50001 * config/alpha/alpha.c (alpha_instantiate_decls): New function. (TARGET_INSTANTIATE_DECLS): New define. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/alpha/alpha.c
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-08-06 18:49:17 UTC --- Just to confirm that the build failure is now fixed. Thanks Jan!
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 --- Comment #5 from uros at gcc dot gnu.org 2011-08-06 18:49:50 UTC --- Author: uros Date: Sat Aug 6 18:49:46 2011 New Revision: 177534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177534 Log: PR target/50001 * config/alpha/alpha.c (alpha_instantiate_decls): New function. (TARGET_INSTANTIATE_DECLS): New define. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/alpha/alpha.c
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 --- Comment #6 from uros at gcc dot gnu.org 2011-08-06 18:54:04 UTC --- Author: uros Date: Sat Aug 6 18:54:01 2011 New Revision: 177535 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177535 Log: PR target/50001 * config/alpha/alpha.c (alpha_instantiate_decls): New function. (TARGET_INSTANTIATE_DECLS): New define. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/alpha.c
[Bug rtl-optimization/50001] [alpha]: ICE in reload_combine_note_use, at postreload.c:1538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50001 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-08/msg00710.htm ||l Resolution||FIXED Target Milestone|--- |4.4.7 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 18:56:38 UTC --- Fixed.
[Bug target/49688] [alpha]: Many execution test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49688 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #24 from Uros Bizjak ubizjak at gmail dot com 2011-08-06 18:58:49 UTC --- Testsuite results are clean with patched gas. Fixed.
[Bug c/44949] extend Wparentheses from to =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44949 --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2011-08-06 20:49:40 UTC --- Created attachment 24935 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24935 hack It is an easy enough hack to call the Wparentheses code for = and others (the warning says instead of =, it isn't a clean patch) so I can test on real code. And it seems painful. It warns on code like: a |= b c; where it is quite clear we could never intend (a|=b)c;. Restricting the warning to the case where the result of the expression is used should improve things, except that I don't know how to access that information...
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||INVALID --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-06 21:08:56 UTC --- I think the c.l.f discussion shows that this is not allowed in Fortran. Closing.
[Bug java/50007] New: org.eclipse.jdt.internal.compiler.batch.GCCMain not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50007
Summary: org.eclipse.jdt.internal.compiler.batch.GCCMain not
found
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vedama...@netscape.net
Not able to compile simple Java source file to bytecode.
* Sample Java source file (HelloWorld.java):
public class HelloWorld {
public int print()
{
System.out.println(Hello world!);
}
}
* When I run gcj-4.6 -C -c HelloWorld.java I get the following results:
Exception in thread main java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(MainThread.java:100)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
at java.lang.ClassLoader.loadClass(ClassLoader.java:452)
at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
at gnu.java.lang.MainThread.run(MainThread.java:96)
My understanding is that main only needs to be defined when linking which is
not what I am trying to do. I just want to compile Java source file to a
.class file.
[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48727 --- Comment #9 from uros at gcc dot gnu.org 2011-08-06 21:37:25 UTC --- Author: uros Date: Sat Aug 6 21:37:22 2011 New Revision: 177537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177537 Log: PR testsuite/48727 * g++.dg/opt/devirt2.C: Use specific pattern for alpha*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/devirt2.C
[Bug c++/49921] [C++0x] Segfault during compilation, decltype and operator-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49921 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-08-06 22:23:19 UTC --- Fixed for 4.6.2.
[Bug c++/48993] [C++0x] segmentation fault when compiling this program with constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48993 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Blocks||48892 Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-08-06 22:22:53 UTC --- Segfault fixed for 4.6.2; now GCC will give a sorry for the constructor definition. Actually fixing the compiler to accept the code will happen under PR 48892.
[Bug c++/49988] constexpr on ctor invokes improper initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49988 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-08-06 22:24:03 UTC --- Fixed for 4.6.2.
[Bug lto/50008] New: [4.7 Regression] type mismatch in array reference, verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50008 Summary: [4.7 Regression] type mismatch in array reference, verify_gimple failed Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 24936 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24936 Testcase
[Bug lto/48259] Internal compiler errors in lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48259 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Known to work||4.7.0 Known to fail|4.7.0 | --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-08-06 23:56:45 UTC --- I can't reproduce it in 4.7.0.
[Bug c/50009] New: [4.7 Regression] Segmentation fault in tree_nop_conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50009
Summary: [4.7 Regression] Segmentation fault in
tree_nop_conversion
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
Target: i686-pc-mingw32
Created attachment 24937
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24937
Backtrace
Testcase:
struct S {
short a;
short b[];
} __attribute__((packed));
Re: [build] Move unwinder to toplevel libgcc (v2)
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: On Fri, Aug 5, 2011 at 20:18, Mikael Morin mikael.mo...@sfr.fr wrote: I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. Adding a -I flag? I suppose that makes sense even if crtstuff is moved soon to toplevel libgcc. How about this? It fixes the problem. Index: gcc/Makefile.in === --- gcc/Makefile.in (révision 177491) +++ gcc/Makefile.in (copie de travail) @@ -1088,7 +1088,7 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include @INCINTL@ \ $(CPPINC) $(GMPINC) $(DECNUMINC) \ - $(PPLINC) $(CLOOGINC) + $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION) Mikael
Re: [PATCH] PR c++/33255 - Support -Wunused-local-typedefs warning
So I finally got back to this and updated the patch according to the comments below. Jason Merrill ja...@redhat.com writes: On 07/27/2011 01:54 PM, Dodji Seketeli wrote: + /* Set of typedefs that are used in this function. */ + struct pointer_set_t * GTY((skip)) used_local_typedefs; Is there a reason not to just use TREE_USED for this? Done now. + /* Vector of locally defined typedefs, for + -Wunused-local-typedefs. */ + VEC(tree,gc) *local_typedefs; If the accessors are in c-common, this field should be in c_language_function. Done, see my comment below. + /* We are only interested in a typedef declared locally. */ + if (DECL_CONTEXT (typedef_decl) != current_function_decl) +return; What if it's used in a nested function/local class/lambda? Oops. Good catch. I have added a local_decl_p predicated and used that instead. I have also added a test case for this. @@ -4175,6 +4175,9 @@ mark_used (tree decl) /* Set TREE_USED for the benefit of -Wunused. */ TREE_USED (decl) = 1; + + maybe_record_local_typedef_use (TREE_TYPE (decl)); Why is this needed? If the decl has the typedef for a type, we should have already marked it as used in grokdeclarator. Actually, couldn't we just mark a typedef as used when when lookup finds it? That would avoid having to mark in so many places and avoid the need for walk_tree. I have done this and it's indeed much better. Thanks. I think -Wunused and -Wall should imply -Wunused-local-typedefs unless the user specifies -Wno-unused-local-typedefs. [...] Does your set of linemap patches fix the issue? In that case, we can add it when those go in. OK. Joseph S. Myers jos...@codesourcery.com writes: On Fri, 29 Jul 2011, Jason Merrill wrote: Looking a bit further, it looks like the C FE uses cfun-language only to store the context of the outer function when faced with a nested function. This is done by c_push_function_context, called by c_parser_declaration_or_fndef. Otherwise, cfun-language is not allocated. Is it appropriate that -Wunused-local-typedefs allocates it as well? I think so. Joseph? Seems reasonable. So I have done this in the C FE. -Wunused-local-typedefs allocates cfun-language when the cfun for the current function is created, and let it be garbage-collected at the end of the current function. Tested on x86_64-unknown-linux-gnu against trunk. gcc/ * c-decl.c (lookup_name): Use the new maybe_record_local_typedef_use. (pushdecl): Use the new record_locally_defined_typedef. (store_parm_decls): Allocate cfun-language. (finish_function): Use the new maybe_warn_unused_local_typedefs, and mark cfunlanguage to be collected. (c_push_function_context): Allocate cfun-language here only if needed. (c_pop_function_context): Likewise, mark cfun-language for collection only when it should be done. * c-typeck.c (c_expr_sizeof_type, c_cast_expr): Use the new maybe_record_local_typedef_use. gcc/c-family * c-common.h (struct c_language_function::local_typedefs): New field. (local_decl_p, record_locally_defined_typedef) (maybe_record_local_typedef_use) (maybe_warn_unused_local_typedefs): Declare new functions. * c-common.c (local_decl_p, record_locally_defined_typedef) (maybe_record_local_typedef_use) (maybe_warn_unused_local_typedefs): Define new functions. * c.opt: Declare new -Wunused-local-typedefs flag. gcc/cp * name-lookup.c (pushdecl_maybe_friend_1): Use the new record_locally_defined_typedef. * cp-tree.h (cp_maybe_record_local_typedef_use): Declare new function. * decl.c (finish_function): Use the new maybe_warn_unused_local_typedefs. * decl2.c (cp_maybe_record_local_typedef_use): New public function. (grokfield): Use the new record_locally_defined_typedef. * parser.c (lookup_name): Use the new cp_maybe_record_local_typedef_use. maybe_record_local_typedef_use. gcc/doc/ * invoke.texi: Update documentation for -Wunused-local-typedefs. gcc/testsuite/ * g++.dg/warn/Wunused-local-typedefs.C: New test file. * c-c++-common/Wunused-local-typedefs.c: Likewise. libstdc++-v3/ * include/ext/bitmap_allocator.h (__detail::__mini_vector::__lower_bound): Remove unused typedef. * src/istream.cc (std::operator(basic_istreamchar __in, basic_stringchar __str)): Likewise. (std::getline): Likewise. * src/valarray.cc (__valarray_product): Likewise. --- gcc/c-decl.c | 38 +- gcc/c-family/c-common.c| 114 +++ gcc/c-family/c-common.h|8 + gcc/c-family/c.opt |4 + gcc/cp/cp-tree.h |
Re: C++ PATCH to allow VLAs with C++0x auto
On 08/05/2011 09:10 PM, Jason Merrill wrote: Paolo asked for GCC to allow deduction of auto from a variable-length array. Since auto doesn't have the issues involved with normal template deduction from VLAs (namely, the type not being link-time constant), this seems reasonable to me. Thanks! Paolo.
[PATCH, i386]: Simplify frame-save_regs_using_mov calculation.
Hello!
No functional changes.
2011-08-06 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_compute_frame_layout): Simplify
frame-save_regs_using_mov calculation.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 177507)
+++ i386.c (working copy)
@@ -8742,16 +8742,12 @@ ix86_compute_frame_layout (struct ix86_frame *fram
cfun-machine-use_fast_prologue_epilogue
= !expensive_function_p (count);
}
- if (TARGET_PROLOGUE_USING_MOVE
- cfun-machine-use_fast_prologue_epilogue)
-frame-save_regs_using_mov = true;
- else
-frame-save_regs_using_mov = false;
- /* If static stack checking is enabled and done with probes, the registers
- need to be saved before allocating the frame. */
- if (flag_stack_check == STATIC_BUILTIN_STACK_CHECK)
-frame-save_regs_using_mov = false;
+ frame-save_regs_using_mov
+= (TARGET_PROLOGUE_USING_MOVE cfun-machine-use_fast_prologue_epilogue
+ /* If static stack checking is enabled and done with probes,
+ the registers need to be saved before allocating the frame. */
+flag_stack_check != STATIC_BUILTIN_STACK_CHECK);
/* Skip return address. */
offset = UNITS_PER_WORD;
[patch testsuite]: Adjust gcc.dg/tree-ssa tests for LLP64 target
Hello,
this adjusts some testcases for LLP64 target x86_64 mingw.
ChangeLog
2011-08-06 Kai Tietz kti...@redhat.com
* gcc.dg/tree-ssa/pr23455.c: Adjust testcases for LLP64 for
x86_64 mingw target.
* gcc.dg/tree-ssa/loop-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-3.c: Likewise.
* gcc.dg/tree-ssa/loop-33.c: Likewise.
* gcc.dg/tree-ssa/ssa-store-ccp-4.c: Likewise.
* gcc.dg/tree-ssa/loop-35.c: Likewise.
* gcc.dg/tree-ssa/stdarg-2.c: Likewise.
* gcc.dg/tree-ssa/stdarg-4.c: Likewise.
* gcc.dg/tree-ssa/stdarg-5.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-11c.c: Likewise.
Tested for x86_64-w64-mingw32, and checked on x86_64-pc-linux-gnu. Ok
for apply?
Regards,
Kai
Index: pr23455.c
===
--- pr23455.c (revision 177507)
+++ pr23455.c (working copy)
@@ -1,19 +1,25 @@
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-pre-stats } */
-unsigned long outcnt;
+#ifdef _WIN64
+#define LONG long long
+#else
+#define LONG long
+#endif
+
+unsigned LONG outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned int *outbuf, unsigned int bi_buf)
{
-unsigned long t1 = outcnt;
+unsigned LONG t1 = outcnt;
outbuf[t1] = bi_buf;
-unsigned long t2 = outcnt;
+unsigned LONG t2 = outcnt;
if (t2 == 16384)
flush_outbuf();
-unsigned long t3 = outcnt;
+unsigned LONG t3 = outcnt;
outbuf[t3] = bi_buf;
}
/* We should eliminate one load of outcnt, which will in turn let us eliminate
Index: loop-1.c
===
--- loop-1.c(revision 177507)
+++ loop-1.c(working copy)
@@ -44,10 +44,11 @@
/* CRIS keeps the address in a register. */
/* m68k sometimes puts the address in a register, depending on CPU and PIC. */
-/* { dg-final { scan-assembler-times foo 5 { xfail hppa*-*-*
ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw*
i?86-*-cygwin* } } } */
+/* { dg-final { scan-assembler-times foo 5 { xfail hppa*-*-*
ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw*
i?86-*-cygwin* x86_64-*-mingw* } } } */
/* { dg-final { scan-assembler-times foo,%r 5 { target hppa*-*-* } } } */
/* { dg-final { scan-assembler-times = foo 5 { target ia64*-*-* } } } */
/* { dg-final { scan-assembler-times call\[ \t\]*_foo 5 { target
i?86-*-mingw* i?86-*-cygwin* } } } */
+/* { dg-final { scan-assembler-times call\[ \t\]*foo 5 { target
x86_64-*-mingw* } } } */
/* { dg-final { scan-assembler-times jsr|bsrf|blink\ttr?,r18 5 {
target sh*-*-* } } } */
/* { dg-final { scan-assembler-times Jsr \\\$r 5 { target cris-*-* } } } */
/* { dg-final { scan-assembler-times \[jb\]sr 5 { target fido-*-*
m68k-*-* } } } */
Index: ssa-store-ccp-2.c
===
--- ssa-store-ccp-2.c (revision 177507)
+++ ssa-store-ccp-2.c (working copy)
@@ -10,5 +10,5 @@
/* There should be a reference to conststaticvariable since it may
may be overriden at link time. */
-/* { dg-final { scan-tree-dump-times conststaticvariable 1 optimized} } */
+/* { dg-final { scan-tree-dump-times conststaticvariable 1
optimized { xfail { *-*-mingw* *-*-cygwin* } } } } */
/* { dg-final { cleanup-tree-dump optimized } } */
Index: ssa-store-ccp-3.c
===
--- ssa-store-ccp-3.c (revision 177507)
+++ ssa-store-ccp-3.c (working copy)
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* Skipped on MIPS GNU/Linux and IRIX target because __PIC__ can be
defined for executables as well as shared libraries. */
-/* { dg-skip-if { *-*-darwin* hppa*64*-*-* mips*-*-linux*
mips*-*-irix* } { * } { } } */
+/* { dg-skip-if { *-*-darwin* hppa*64*-*-* mips*-*-linux*
mips*-*-irix* *-*-mingw* } { * } { } } */
/* { dg-options -O2 -fno-common -fdump-tree-optimized } */
const int conststaticvariable;
Index: loop-33.c
===
--- loop-33.c (revision 177507)
+++ loop-33.c (working copy)
@@ -36,5 +36,5 @@
}
}
-/* { dg-final { scan-tree-dump-times Executing store motion of 4
lim1 { xfail lp64 } } } */
+/* { dg-final { scan-tree-dump-times Executing store motion of 4
lim1 { xfail { lp64 || llp64 } } } } */
/* { dg-final { cleanup-tree-dump lim1 } } */
Index: ssa-store-ccp-4.c
===
--- ssa-store-ccp-4.c (revision 177507)
+++ ssa-store-ccp-4.c (working copy)
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-require-effective-target fpic } */
-/* { dg-skip-if { *-*-darwin* } { * } { } } */
+/* { dg-skip-if { *-*-darwin* *-*-mingw* } { * } { } } */
/* { dg-options -O2 -fno-common -fpic -fdump-tree-optimized } */
const int conststaticvariable;
Index: loop-35.c
PATCH: Add testcases for PRs 48084/49504/49860
Hi,
I checked in this patch to add testcases for PRs 48084/49504/49860.
H.J.
Index: gcc.target/i386/pr49504.c
===
--- gcc.target/i386/pr49504.c (revision 0)
+++ gcc.target/i386/pr49504.c (revision 0)
@@ -0,0 +1,18 @@
+/* PR target/49504 */
+/* { dg-do run { target { x32 } } } */
+/* { dg-options -O } */
+
+unsigned long long
+foo (const void* p, unsigned long long q)
+{
+ unsigned long long a = (((unsigned long long) ((unsigned long) p)) + q)
32;
+ return a;
+}
+
+int
+main ()
+{
+ if (foo (foo, 0x1ULL) != 0x1)
+__builtin_abort ();
+ return 0;
+}
Index: gcc.target/i386/pr48084-3.c
===
--- gcc.target/i386/pr48084-3.c (revision 0)
+++ gcc.target/i386/pr48084-3.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -msse3 } */
+
+void
+_mm_monitor (void const * __P, unsigned int __E, unsigned int __H)
+{
+ __builtin_ia32_monitor (__P, __E, __H);
+}
Index: gcc.target/i386/pr48084-5.c
===
--- gcc.target/i386/pr48084-5.c (revision 0)
+++ gcc.target/i386/pr48084-5.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options -O0 -mrdrnd } */
+
+int
+_rdrand16_step (unsigned short *__P)
+{
+ return __builtin_ia32_rdrand16_step (__P);
+}
Index: gcc.target/i386/pr48084-2.c
===
--- gcc.target/i386/pr48084-2.c (revision 0)
+++ gcc.target/i386/pr48084-2.c (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -msse2 } */
+
+typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
+typedef char __v8qi __attribute__ ((__vector_size__ (8)));
+void
+_mm_maskmove_si64 (__m64 __A, __m64 __N, char *__P)
+{
+__builtin_ia32_maskmovq ((__v8qi)__A, (__v8qi)__N, __P);
+}
Index: gcc.target/i386/pr48084-4.c
===
--- gcc.target/i386/pr48084-4.c (revision 0)
+++ gcc.target/i386/pr48084-4.c (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options -O0 -msse2 } */
+
+void
+_mm_clflush (void const *__A)
+{
+ __builtin_ia32_clflush (__A);
+}
Index: gcc.target/i386/pr48084-1.c
===
--- gcc.target/i386/pr48084-1.c (revision 0)
+++ gcc.target/i386/pr48084-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -msse2 } */
+
+typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
+typedef float __v2sf __attribute__ ((__vector_size__ (8)));
+typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
+typedef float __v4sf __attribute__ ((__vector_size__ (16)));
+void
+_mm_storeh_pi (__m64 *__P, __m128 __A)
+{
+ __builtin_ia32_storehps ((__v2sf *)__P, (__v4sf)__A);
+}
Index: gcc.dg/pr49860.c
===
--- gcc.dg/pr49860.c(revision 0)
+++ gcc.dg/pr49860.c(revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do assemble } */
+/* { dg-options -O3 -funroll-all-loops } */
+
+extern char inbuf[];
+extern char outbuf[];
+extern unsigned insize;
+extern unsigned inptr;
+static int max_len;
+static int peek_bits;
+void build_tree() {
+ int len;
+ char *prefixp;
+ max_len = inbuf[inptr++];
+ peek_bits = ((max_len) = (12) ? (max_len) : (12));
+ prefixp = outbuf[1peek_bits];
+ for (len = 1;
+ len = peek_bits;
+ len++) {
+ }
+ while (prefixp outbuf) *--prefixp = 0;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177508)
+++ ChangeLog (working copy)
@@ -1,3 +1,18 @@
+2011-08-06 H.J. Lu hongjiu...@intel.com
+
+ PR target/48084
+ * gcc.target/i386/pr48084-1.c: New.
+ * gcc.target/i386/pr48084-2.c: Likewise.
+ * gcc.target/i386/pr48084-3.c: Likewise.
+ * gcc.target/i386/pr48084-4.c: Likewise.
+ * gcc.target/i386/pr48084-5.c: Likewise.
+
+ PR rtl-optimization/49504
+ * gcc.target/i386/pr49504.c: New.
+
+ PR target/49860
+ * gcc.dg/pr49860.c: New.
+
2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
PR libobjc/49882
libobjc: Fix PR libobjc/50002 (class_replaceMethod does not work on class methods)
This patch fixes PR libobjc/50002. The problem was that replacing an existing
class method wouldn't work
because the messaging tables weren't being refreshed for class methods when a
method was replaced.
This patch also includes three other related changes:
* a new couple of comprehensive testcases, gnu-api-2-class-meta.m and
gnu-api-2-class-meta.mm, covering
calling various runtime functions with a meta class (as opposed to a normal
class) as argument. This tests the
above-mentioned fix for libobjc/50002, but also a variety of other similar
functions and situations (this is mostly
for peace of mind - I wanted to be sure that there aren't other problems
similar to libobjc/50002).
* a fix for a small issue with class_getSuperclass() (when used on a meta
class in construction), which was
identified by the testcases above. The actual problem is actually related to
libobjc/49882 - which I fixed this
morning.
* synchronizes the ObjC++ testsuite with the ObjC one. In particular, when
fixing libobjc/49882 this morning
I added an ObjC testcase but forgot to add an ObjC++ one. This patch includes
it.
Tested with GNU and Apple runtime. Committed to trunk.
Thanks
Index: libobjc/ChangeLog
===
--- libobjc/ChangeLog (revision 177506)
+++ libobjc/ChangeLog (working copy)
@@ -1,5 +1,17 @@
2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
+ PR libobjc/50002
+ * class.c (__objc_update_classes_with_methods): Iterate over meta
+ classes as well as normal classes when refreshing the method
+ implementations. This fixes replacing class methods.
+
+2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
+
+ * class.c (class_getSuperclass): Fixed to work with meta classes
+ still in construction too.
+
+2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
+
* class.c (class_getSuperclass): Fixed typo in comment.
2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
Index: libobjc/class.c
===
--- libobjc/class.c (revision 177506)
+++ libobjc/class.c (working copy)
@@ -781,35 +781,57 @@ __objc_update_classes_with_methods (struct objc_me
while (node != NULL)
{
- /* Iterate over all methods in the class. */
- Class class = node-pointer;
- struct objc_method_list * method_list = class-methods;
+ /* We execute this loop twice: the first time, we iterate
+over all methods in the class (instance methods), while
+the second time we iterate over all methods in the meta
+class (class methods). */
+ Class class = Nil;
+ BOOL done = NO;
- while (method_list)
+ while (done == NO)
{
- int i;
+ struct objc_method_list * method_list;
- for (i = 0; i method_list-method_count; ++i)
+ if (class == Nil)
{
- struct objc_method *method = method_list-method_list[i];
+ /* The first time, we work on the class. */
+ class = node-pointer;
+ }
+ else
+ {
+ /* The second time, we work on the meta class. */
+ class = class-class_pointer;
+ done = YES;
+ }
- /* If the method is one of the ones we are looking
-for, update the implementation. */
- if (method == method_a)
- sarray_at_put_safe (class-dtable,
- (sidx) method_a-method_name-sel_id,
- method_a-method_imp);
+ method_list = class-methods;
- if (method == method_b)
+ while (method_list)
+ {
+ int i;
+
+ for (i = 0; i method_list-method_count; ++i)
{
- if (method_b != NULL)
+ struct objc_method *method = method_list-method_list[i];
+
+ /* If the method is one of the ones we are
+looking for, update the implementation. */
+ if (method == method_a)
sarray_at_put_safe (class-dtable,
- (sidx)
method_b-method_name-sel_id,
- method_b-method_imp);
+ (sidx)
method_a-method_name-sel_id,
+ method_a-method_imp);
+
+ if (method == method_b)
+ {
+ if (method_b != NULL)
+ sarray_at_put_safe (class-dtable,
+
PATCH: Add testcases for PRs 47766/47715
Hi,
I checked in this patch to add testcases for PRs 47766/47715.
H.J.
---
Index: gcc.dg/pr47766.c
===
--- gcc.dg/pr47766.c(revision 0)
+++ gcc.dg/pr47766.c(revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fstack-protector } */
+/* { dg-require-effective-target fstack_protector } */
+
+int
+parse_opt (int key)
+{
+ struct
+ {
+ int arg[key];
+ } reqdata;
+ return 0;
+}
Index: gcc.dg/tls/pr47715-1.c
===
--- gcc.dg/tls/pr47715-1.c (revision 0)
+++ gcc.dg/tls/pr47715-1.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fPIC } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int h_errno;
+int *
+__h_errno_location (void)
+{
+ return h_errno;
+}
Index: gcc.dg/tls/pr47715-2.c
===
--- gcc.dg/tls/pr47715-2.c (revision 0)
+++ gcc.dg/tls/pr47715-2.c (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fPIC } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int *__libc_resp;
+int
+__res_init(void) {
+ return *__libc_resp;
+}
Index: gcc.dg/tls/pr47715-3.c
===
--- gcc.dg/tls/pr47715-3.c (revision 0)
+++ gcc.dg/tls/pr47715-3.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fPIC } */
+/* { dg-require-effective-target tls } */
+
+struct initial_sp
+{
+ void *sp;
+ long len;
+};
+__thread
+struct initial_sp __morestack_initial_sp;
+void bar (void *);
+void
+foo ()
+{
+ bar (__morestack_initial_sp.len);
+}
Index: gcc.dg/tls/pr47715-4.c
===
--- gcc.dg/tls/pr47715-4.c (revision 0)
+++ gcc.dg/tls/pr47715-4.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options -O0 } */
+/* { dg-require-effective-target tls } */
+
+struct gomp_team_state
+{
+ struct gomp_team_state *prev_ts;
+ unsigned team_id;
+ unsigned level;
+};
+struct gomp_thread
+{
+ void *data;
+ struct gomp_team_state ts;
+};
+extern __thread struct gomp_thread gomp_tls_data;
+int
+foo (int level)
+{
+ struct gomp_team_state *ts = gomp_tls_data.ts;
+ if (level 0 || level ts-level)
+return -1;
+ return ts-team_id;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177510)
+++ ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2011-08-06 H.J. Lu hongjiu...@intel.com
+
+ PR target/47766
+ * gcc.dg/pr47766.c: New.
+
+ PR target/47715
+ * gcc.dg/tls/pr47715-1.c: New.
+ * gcc.dg/tls/pr47715-2.c: Likewise.
+ * gcc.dg/tls/pr47715-3.c: Likewise.
+ * gcc.dg/tls/pr47715-4.c: Likewise.
+
2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
PR libobjc/50002
Re: [build] Move unwinder to toplevel libgcc (v2)
On 08/06/2011 12:43 PM, Mikael Morin wrote: On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: On Fri, Aug 5, 2011 at 20:18, Mikael Morinmikael.mo...@sfr.fr wrote: I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. Adding a -I flag? I suppose that makes sense even if crtstuff is moved soon to toplevel libgcc. How about this? It fixes the problem. Index: gcc/Makefile.in === --- gcc/Makefile.in (révision 177491) +++ gcc/Makefile.in (copie de travail) @@ -1088,7 +1088,7 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include @INCINTL@ \ $(CPPINC) $(GMPINC) $(DECNUMINC) \ - $(PPLINC) $(CLOOGINC) + $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION) Thanks. Can you try this instead? Paolo 2011-08-06 Paolo Bonzini bonz...@gnu.org Mikael Morin mikael.mo...@sfr.fr * Makefile.in (INCLUDES_FOR_TARGET): New. (LIBGCC2_CFLAGS): Use it. (CRTSTUFF_CFLAGS): Use it instead of INCLUDES. Index: ../gcc/gcc/Makefile.in === --- ../gcc/gcc/Makefile.in (revision 177266) +++ ../gcc/gcc/Makefile.in (working copy) @@ -668,9 +668,9 @@ endif # Options to use when compiling libgcc2.a. # LIBGCC2_DEBUG_CFLAGS = -g -LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) \ - $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \ - -DIN_LIBGCC2 \ +LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(INCLUDES_FOR_TARGET) $(GCC_CFLAGS) \ + $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) \ + $(GTHREAD_FLAGS) -DIN_LIBGCC2 \ -fbuilding-libgcc -fno-stack-protector \ $(INHIBIT_LIBC_CFLAGS) @@ -682,8 +682,8 @@ LIBGCC2_INCLUDES = TARGET_LIBGCC2_CFLAGS = # Options to use when compiling crtbegin/end. -CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \ - -finhibit-size-directive -fno-inline -fno-exceptions \ +CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES_FOR_TARGET) $(MULTILIB_CFLAGS) \ + -g0 -finhibit-size-directive -fno-inline -fno-exceptions \ -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \ -fno-stack-protector \ $(INHIBIT_LIBC_CFLAGS) @@ -1102,6 +1102,9 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(s $(CPPINC) $(GMPINC) $(DECNUMINC) \ $(PPLINC) $(CLOOGINC) +INCLUDES_FOR_TARGET = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ + -I$(srcdir)/../include $(DECNUMINC) -I$(srcdir)/../libgcc + .c.o: $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION)
PATCH: Add testcases for PRs 47449/47446
Hi,
I checked in this patch to add testcases for PRs 47449/47446.
H.J.
Index: gcc.target/i386/pr47449.c
===
--- gcc.target/i386/pr47449.c (revision 0)
+++ gcc.target/i386/pr47449.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+void bar (void *, void *);
+int
+foo (void *p1, void *p2)
+{
+ int ret1, ret2;
+ __asm ( : =D (ret1), =S (ret2));
+ bar (p1, p2);
+ return ret1 + ret2;
+}
Index: gcc.dg/pr47446-1.c
===
--- gcc.dg/pr47446-1.c (revision 0)
+++ gcc.dg/pr47446-1.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-do assemble } */
+/* { dg-options -O2 } */
+
+extern void abort (void);
+enum
+{
+ __GCONV_OK = 0,
+ __GCONV_NOCONV,
+ __GCONV_NODB,
+ __GCONV_NOMEM,
+ __GCONV_EMPTY_INPUT,
+ __GCONV_FULL_OUTPUT,
+ __GCONV_ILLEGAL_INPUT,
+ __GCONV_INCOMPLETE_INPUT,
+ __GCONV_ILLEGAL_DESCRIPTOR,
+ __GCONV_INTERNAL_ERROR
+};
+int
+foo (int result)
+{
+ int irreversible = 0;
+ switch (result)
+{
+case __GCONV_ILLEGAL_INPUT:
+ irreversible = -1L;
+ break;
+case __GCONV_FULL_OUTPUT:
+ irreversible = -2L;
+ break;
+case __GCONV_INCOMPLETE_INPUT:
+ irreversible = -3L;
+ break;
+case __GCONV_EMPTY_INPUT:
+case __GCONV_OK:
+ break;
+default:
+ abort ();
+}
+ return irreversible;
+}
Index: gcc.dg/pr47446-2.c
===
--- gcc.dg/pr47446-2.c (revision 0)
+++ gcc.dg/pr47446-2.c (revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fpic } */
+
+extern void abort (void);
+enum
+{
+ __GCONV_OK = 0,
+ __GCONV_NOCONV,
+ __GCONV_NODB,
+ __GCONV_NOMEM,
+ __GCONV_EMPTY_INPUT,
+ __GCONV_FULL_OUTPUT,
+ __GCONV_ILLEGAL_INPUT,
+ __GCONV_INCOMPLETE_INPUT,
+ __GCONV_ILLEGAL_DESCRIPTOR,
+ __GCONV_INTERNAL_ERROR
+};
+int
+foo (int result)
+{
+ int irreversible = 0;
+ switch (result)
+{
+case __GCONV_ILLEGAL_INPUT:
+ irreversible = -1L;
+ break;
+case __GCONV_FULL_OUTPUT:
+ irreversible = -2L;
+ break;
+case __GCONV_INCOMPLETE_INPUT:
+ irreversible = -3L;
+ break;
+case __GCONV_EMPTY_INPUT:
+case __GCONV_OK:
+ break;
+default:
+ abort ();
+}
+ return irreversible;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177511)
+++ ChangeLog (working copy)
@@ -1,5 +1,14 @@
2011-08-06 H.J. Lu hongjiu...@intel.com
+ PR middle-end/47449
+ * gcc.target/i386/pr47449.c: New.
+
+ PR target/47446
+ * gcc.dg/pr47446-1.c: New.
+ * gcc.dg/pr47446-2.c: Likewise.
+
+2011-08-06 H.J. Lu hongjiu...@intel.com
+
PR target/47766
* gcc.dg/pr47766.c: New.
Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections
PING.
On Fri, Jul 22, 2011 at 7:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 22, 2011 at 7:00 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
@@ -2660,6 +2664,7 @@ esac
case ${target} in
i[34567]86-*-linux* | x86_64-*-linux*)
tmake_file=${tmake_file} i386/t-pmm_malloc i386/t-i386
+ use_initfini_array=yes
;;
i[34567]86-*-* | x86_64-*-*)
tmake_file=${tmake_file} i386/t-gmm_malloc i386/t-i386
What is i?86/x86_64 specific on it? Don't most other glibc targets
want to use it too, perhaps with some arch specific tweaks?
I do have a patch for all ELF targets:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01416.html
It touches many targets. . But I only have one feedback from one
target maintainer. I don't know how long it will take to review it.
--- /dev/null
+++ b/gcc/config/initfini-array.c
This is ugly. varasm.c already has lots of ELF specific code, simply
put them there as well and only let configury set some macro which will
allow targets to choose which of the implementations in the generic code
they want to use (or if they want their own which e.g. calls the generic
routine and does something additional to it etc.). The sections probably
can be created only the first time you actually need them.
I will do that.
--- a/gcc/crtstuff.c
+++ b/gcc/crtstuff.c
@@ -189,6 +190,9 @@ typedef void (*func_ptr) (void);
refer to only the __CTOR_END__ symbol in crtend.o and the
__DTOR_LIST__
symbol in crtbegin.o, where they are defined. */
+/* No need for .ctors/.dtors section if linker can place them in
+ .init_array/.fini_array section. */
+#ifndef NO_CTORS_DTORS_SECTIONS
/* The -1 is a flag to __do_global_[cd]tors indicating that this table
does not start with a count of elements. */
#ifdef CTOR_LIST_BEGIN
@@ -219,6 +223,7 @@ STATIC func_ptr __DTOR_LIST__[1]
__attribute__((section(.dtors), aligned(sizeof(func_ptr
= { (func_ptr) (-1) };
#endif /* __DTOR_LIST__ alternatives */
+#endif /* NO_CTORS_DTORS_SECTIONS */
#ifdef USE_EH_FRAME_REGISTRY
/* Stick a label at the beginning of the frame unwind info so we can
register
@@ -489,6 +494,9 @@ __do_global_ctors_1(void)
#elif defined(CRT_END) /* ! CRT_BEGIN */
+/* No need for .ctors/.dtors section if linker can place them in
+ .init_array/.fini_array section. */
+#ifndef NO_CTORS_DTORS_SECTIONS
/* Put a word containing zero at the end of each of our two lists of
function
addresses. Note that the words defined here go into the .ctors and
.dtors
sections of the crtend.o file, and since that file is always linked in
@@ -534,6 +542,7 @@ STATIC func_ptr __DTOR_END__[1]
__attribute__((used, section(.dtors), aligned(sizeof(func_ptr
= { (func_ptr) 0 };
#endif
+#endif /* NO_CTORS_DTORS_SECTIONS */
#ifdef EH_FRAME_SECTION_NAME
/* Terminate the frame unwind info section with a 4byte 0 as a sentinel;
I don't see how you can do this. It would IMO break any time you link code
built by different gcc versions where some code emitted by the older gcc
used .ctors or .dtors.
crtstuff.c is used to generate crt*.o, which is the part of GCC. You only
use
it with the GCC you are using. Since your GCC doesn't put anything in
.ctors/.dtors section, you don't need them. As for .o files generated by
old GCCs, that is the linker test, use_initfini_array, is for. The newer
linker
can put input .ctors/.dtors sections in output .init_array/,fini_array
sections.
Here is the updated patch. Any comments?
Thanks.
--
H.J.
---
2011-07-22 H.J. Lu hongjiu...@intel.com
PR target/46770
* config.gcc (use_initfini_array): New variable.
Use .init_arary/.fini_array if they are supported.
* crtstuff.c: Don't generate .ctors nor .dtors sections if
USE_INITFINI_ARRAY is defined.
* output.h (default_initfini_array_init_sections): New.
* varasm.c (elf_init_array_section): Likewise.
(elf_fini_array_section): Likewise.
(get_elf_initfini_array_priority_section): Likewise.
(default_elf_init_array_asm_out_constructor): Likewise.
(default_elf_fini_array_asm_out_destructor): Likewise.
(default_initfini_array_init_sections): Likewise.
* config/initfini-array.h: New.
* config/t-initfini-array: Likewise.
No need for config/t-initfini-array. Here is the updated patch.
--
H.J.
2011-07-22 H.J. Lu hongjiu...@intel.com
PR target/46770
* config.gcc (use_initfini_array): New variable.
Use .init_arary/.fini_array if they are supported.
* crtstuff.c: Don't generate .ctors nor .dtors sections if
USE_INITFINI_ARRAY is defined.
* output.h
Re: [PATCH] Handle BIT_NOT_EXPR in VRP
On 08/05/2011 02:31 PM, Richard Guenther wrote: This extends VRP to handle BIT_NOT_EXPR by composing ~X as -X - 1 (which should give us anti-range handling for free). Just a small detail, but why not -1 - X which saves the NEGATE_EXPR? :) Paolo
PATCH: Add testcases for PRs 47727/47372/47715
Hi,
I checkd in this patch to add testcases for PRs 47727/47372/47715.
H.J.
--
Index: gcc.dg/pr47372-2.c
===
--- gcc.dg/pr47372-2.c (revision 0)
+++ gcc.dg/pr47372-2.c (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fPIC -g } */
+
+typedef unsigned short ush;
+typedef ush Pos;
+extern ush prev[];
+void fill_window( unsigned more, unsigned m)
+{
+unsigned n;
+for (n = 0; n (unsigned)(115); n++) {
+ (prev+0x8000)[n] = (Pos)(m = 0x8000 ? m-0x8000 : 0);
+}
+for (n = 0; n 0x8000; n++) {
+ prev[n] = (Pos)(m = 0x8000 ? m-0x8000 : 0);
+}
+}
Index: gcc.dg/tls/pr47715-5.c
===
--- gcc.dg/tls/pr47715-5.c (revision 0)
+++ gcc.dg/tls/pr47715-5.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-require-effective-target tls } */
+
+extern __thread int __libc_errno __attribute__ ((tls_model (initial-exec)));
+;
+int *
+__errno_location (void)
+{
+ return __libc_errno;
+}
Index: gcc.dg/pr47727.c
===
--- gcc.dg/pr47727.c(revision 0)
+++ gcc.dg/pr47727.c(revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+typedef void (*func_ptr) (void);
+static func_ptr __CTOR_END__[1] = { (func_ptr) 0 };
+static void __attribute__((used))
+__do_global_ctors_aux (void)
+{
+ func_ptr *p;
+ for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
+(*p) ();
+}
Index: gcc.dg/pr47372-1.c
===
--- gcc.dg/pr47372-1.c (revision 0)
+++ gcc.dg/pr47372-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options -O2 -fPIC -g } */
+
+typedef struct FILE FILE;
+int _fwalk(int (*)(FILE *));
+int __sflush(FILE *);
+int
+fflush(FILE *fp)
+{
+ return (_fwalk(__sflush));
+}
Index: ChangeLog
===
--- ChangeLog (revision 177512)
+++ ChangeLog (working copy)
@@ -1,5 +1,14 @@
2011-08-06 H.J. Lu hongjiu...@intel.com
+ PR middle-end/47727
+ * gcc.dg/pr47727.c: New.
+
+ PR target/47372
+ * gcc.dg/pr47372-1.c: New.
+ * gcc.dg/pr47372-2.c: Likewise.
+
+2011-08-06 H.J. Lu hongjiu...@intel.com
+
PR middle-end/47449
* gcc.target/i386/pr47449.c: New.
@@ -17,6 +26,7 @@
* gcc.dg/tls/pr47715-2.c: Likewise.
* gcc.dg/tls/pr47715-3.c: Likewise.
* gcc.dg/tls/pr47715-4.c: Likewise.
+ * gcc.dg/tls/pr47715-5.c: Likewise.
2011-08-06 Nicola Pero nicola.p...@meta-innovation.com
PATCH: Add testcases for PR 47381
Hi,
I checked in this patch to add testcases for PR 47381.
H.J.
---
Index: gcc.target/i386/pr47381.c
===
--- gcc.target/i386/pr47381.c (revision 0)
+++ gcc.target/i386/pr47381.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -march=atom } */
+
+struct foo_t {
+ int limit;
+} foo[3];
+void
+bar () {
+ int i;
+ for (i = 0; i 3; i++) {
+__builtin_memset (foo[i], 0, sizeof(*foo));
+ }
+}
Index: gcc.dg/pr47381-2.c
===
--- gcc.dg/pr47381-2.c (revision 0)
+++ gcc.dg/pr47381-2.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+typedef unsigned long ulg;
+long block_start;
+typedef unsigned char uch;
+extern uch window[];
+ unsigned strstart;
+ulg flush_block (char *buf, ulg stored_len, int eof);
+ulg deflate()
+{
+return flush_block(block_start = 0L ?
(char*)window[(unsigned)block_start] : (char*)((void *)0), (long)strstart -
block_start, (1));
+}
Index: gcc.dg/pr47381-1.c
===
--- gcc.dg/pr47381-1.c (revision 0)
+++ gcc.dg/pr47381-1.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+typedef unsigned IPos;
+typedef unsigned char uch;
+extern uch window[];
+unsigned max_chain_length;
+unsigned strstart;
+int longest_match(IPos cur_match, int len, int best_len)
+{
+unsigned chain_length = max_chain_length;
+register uch *scan = window + strstart;
+register uch *match;
+register uch scan_end1 = scan[best_len-1];
+register uch scan_end = scan[best_len];
+do {
+;
+match = window + cur_match;
+if (match[best_len] != scan_end ||
+match[best_len-1] != scan_end1 ||
+*match != *scan ||
+*++match != scan[1]) continue;
+best_len = len;
+} while ( --chain_length != 0);
+return best_len;
+}
Index: ChangeLog
===
--- ChangeLog (revision 177513)
+++ ChangeLog (working copy)
@@ -1,5 +1,12 @@
2011-08-06 H.J. Lu hongjiu...@intel.com
+ PR target/47381
+ * gcc.dg/pr47381-1.c: New.
+ * gcc.dg/pr47381-2.c: Likewise.
+ * gcc.target/i386/pr47381.c: Likewise.
+
+2011-08-06 H.J. Lu hongjiu...@intel.com
+
PR middle-end/47727
* gcc.dg/pr47727.c: New.
Re: [build] Move unwinder to toplevel libgcc (v2)
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: Can you try this instead? It works. Thanks Mikael
Re: [build] Move unwinder to toplevel libgcc (v2)
On 08/06/2011 05:07 PM, Mikael Morin wrote: On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: Can you try this instead? It works. Thanks Committed, thanks. Paolo
[patch, Fortran, committed] Fix PR 50004
Hello world,
I have committed the attached patch as obvious after regression-testing.
The problem was that gfc_typenode_for_spec was clobbering the typespec
for the ISO C types by converting them to integer.
Don't know why I hadn't seen this before.
Regards
Thomas
2011-08-06 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/50004
* target-memory.c (gfc_target_expr-size): Don't clobber typespec
for derived types.
* simplify.c (gfc_simplify_transfer): Don't calculate source_size
twice.
Index: target-memory.c
===
--- target-memory.c (Revision 177487)
+++ target-memory.c (Arbeitskopie)
@@ -120,8 +120,14 @@ gfc_target_expr_size (gfc_expr *e)
case BT_HOLLERITH:
return e-representation.length;
case BT_DERIVED:
- type = gfc_typenode_for_spec (e-ts);
- return int_size_in_bytes (type);
+ {
+ /* Determine type size without clobbering the typespec for ISO C
+ binding types. */
+ gfc_typespec ts;
+ ts = e-ts;
+ type = gfc_typenode_for_spec (ts);
+ return int_size_in_bytes (type);
+ }
default:
gfc_internal_error (Invalid expression in gfc_target_expr_size.);
return 0;
Index: simplify.c
===
--- simplify.c (Revision 177487)
+++ simplify.c (Arbeitskopie)
@@ -6048,8 +6048,6 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr
gfc_array_size (source, tmp) == FAILURE)
gfc_internal_error (Failure getting length of a constant array.);
- source_size = gfc_target_expr_size (source);
-
/* Create an empty new expression with the appropriate characteristics. */
result = gfc_get_constant_expr (mold-ts.type, mold-ts.kind,
source-where);
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Janus,
2011/8/5 Mikael Morinmikael.mo...@sfr.fr:
On Friday 05 August 2011 23:02:33 Thomas Koenig wrote:
The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding procedure are
required to have the same names as in the base procedure.
Could you explain for which cases this test is too strict?
For dummy arguments. If they are corresponding (same position, same name),
they should compare equal. Cf the PR.
The string length expressions of overridden procedures have to be
identical, but with exchanged dummy arguments. Since the dummy
arguments of overridden procedures must have the same name as in the
base procedure, it is sufficient the check for equal names. Checking
for equal symbols would be too strict.
I just tested the following patch:
Index: dependency.c
===
--- dependency.c(Revision 177487)
+++ dependency.c(Arbeitskopie)
@@ -123,7 +123,7 @@ gfc_are_identical_variables (gfc_expr *e1, gfc_exp
{
gfc_ref *r1, *r2;
- if (e1-symtree-n.sym != e2-symtree-n.sym)
+ if (strcmp(e1-symtree-n.sym-name, e2-symtree-n.sym-name))
return false;
/* Volatile variables should never compare equal to themselves. */
without any regressions. Can anybody think of a case where the names
can be identical, but the variables different? (I can't).
Maybe we can relax the test that way and get rid of the large number
of changes for gfc_dep_compare_expr everywhere (which I confess I
dislike, but I can hardly find fault with something that I have done
only yesterday, although the number of changes was much smaller there :-)
1) I have moved 'check_typebound_override' to interface.c and prefixed
it with 'gfc_'.
OK.
2) I have added the 'var_name_only flag' also to
gfc_are_identical_variables, gfc_dep_compare_functions,
identical_array_ref, check_section_vs_section and gfc_is_same_range. I
hope there is nothing else I missed.
See above; could we avoid that?
3) I have made 'gfc_are_identical_variables' static and removed the
gfc prefix (it does not seem to be used outside of dependency.c).
OK.
4) I have made 'gfc_is_same_range' static and removed the gfc prefix
(there is only a commented out reference to it in trans-array.c, so I
commented out the declaration in dependency.h, too). Also I removed
the 'def' argument, which gets always passed a '0'.
OK.
As Thomas mentions, certain cases are still not handled correctly
(e.g. A+B+C vs C+B+A, and other mathematical transformations), but I
hope they are sufficiently exotic (so that we can wait for bug reports
to roll in). In addition I expect people to declare overridden
procedures analogously to the base procedure, and not use e.g.
len=3*(x+1) in one case and len=3*x+3 in the other.
Not OK.
It is wrong to assume that expressions are unequal because we cannot
prove they are equal, with all the limitations that we currently
have. This will introduce rejects-valid bugs.
Please change
+ /* Check string length. */
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl old_target-result-ts.u.cl
+ gfc_dep_compare_expr (proc_target-result-ts.u.cl-length,
+ old_target-result-ts.u.cl-length,
+ true) != 0)
to something like (untested)
+ /* Check string length. */
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl old_target-result-ts.u.cl
+ {
+int len_comparision;
+len_comparison = gfc_dep_compare_expr
(proc_target-result-ts.u.cl-length,
+ old_target-result-ts.u.cl-length);
+if (len_comparison != 0 len_comparison != -2)
...
Alternatively, you could raise an error for 1 and -1 and warn only for
-2 (... may be different).
Regards
Thomas
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Saturday 06 August 2011 17:39:06 Thomas Koenig wrote: As Thomas mentions, certain cases are still not handled correctly (e.g. A+B+C vs C+B+A, and other mathematical transformations), but I hope they are sufficiently exotic (so that we can wait for bug reports to roll in). In addition I expect people to declare overridden procedures analogously to the base procedure, and not use e.g. len=3*(x+1) in one case and len=3*x+3 in the other. Not OK. It is wrong to assume that expressions are unequal because we cannot prove they are equal, with all the limitations that we currently have. This will introduce rejects-valid bugs. In the PR at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 I quote the standard: 4.5.7.3 (type-bound procedure overriding) has: • Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3). 12.3.3 (Characteristics of function results): If a type parameter of a function result or a bound of a function result array is not a constant expression, the exact dependence on the entities in the expression is a characteristic So the standards is more restrictive than expression values being the same. It requires _the exact same dependence on the entities_. My reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you pointed out: a+b+c vs c+b+a (without brackets). Mikael
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
It is wrong to assume that expressions are unequal because we cannot prove they are equal, with all the limitations that we currently have. This will introduce rejects-valid bugs. In the PR at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 I quote the standard: 4.5.7.3 (type-bound procedure overriding) has: • Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3). 12.3.3 (Characteristics of function results): If a type parameter of a function result or a bound of a function result array is not a constant expression, the exact dependence on the entities in the expression is a characteristic So the standards is more restrictive than expression values being the same. It requires _the exact same dependence on the entities_. My reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you pointed out: a+b+c vs c+b+a (without brackets). Huh, I don't see what is so different between 1) 3*(x+1) vs 3*x+3 and 2) a+b+c vs c+b+a In both cases the expressions look different at first sight, but can be transformed into each other mathematically. So I'd say they are mathematically equivalent, although the spelled-out representations of these expressions differ. The question is how you interpret the standard's formulation of exact dependence on the entities in the expression. Naively I would have taken this to mean the *mathematical* dependence (which can be represented by different actual expressions). But I'm fine with your interpretation, too, which will make life even easier for us. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Hi Thomas,
The string length expressions of overridden procedures have to be
identical, but with exchanged dummy arguments. Since the dummy
arguments of overridden procedures must have the same name as in the
base procedure, it is sufficient the check for equal names. Checking
for equal symbols would be too strict.
I just tested the following patch:
Index: dependency.c
===
--- dependency.c (Revision 177487)
+++ dependency.c (Arbeitskopie)
@@ -123,7 +123,7 @@ gfc_are_identical_variables (gfc_expr *e1, gfc_exp
{
gfc_ref *r1, *r2;
- if (e1-symtree-n.sym != e2-symtree-n.sym)
+ if (strcmp(e1-symtree-n.sym-name, e2-symtree-n.sym-name))
return false;
/* Volatile variables should never compare equal to themselves. */
without any regressions. Can anybody think of a case where the names can be
identical, but the variables different? (I can't).
Well, I'd say this can only happen if both variables reside in
different namespaces (i.e. different modules or procedures).
Maybe we can relax the test that way and get rid of the large number
of changes for gfc_dep_compare_expr everywhere (which I confess I
dislike, but I can hardly find fault with something that I have done
only yesterday, although the number of changes was much smaller there :-)
Ok, I don't like the large number of changes either, but I assumed
they were necessary.
I have to admit I'm not aware of all the cases that
'gfc_dep_compare_expr' was intended for originally. I was only trying
to re-use it for checking overriding procedures, which seems to work
very well, except for the variable names vs. symbols issue. If you
tell me it's fine to only check for variable names everywhere, this is
of course fine.
Btw, the fact that your patch has no regressions does not necessarily
mean that there are no cases where it could fail. It could just mean
that the testsuite does not cover these cases.
Cheers,
Janus
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
On Saturday 06 August 2011 18:06:58 Janus Weil wrote: It is wrong to assume that expressions are unequal because we cannot prove they are equal, with all the limitations that we currently have. This will introduce rejects-valid bugs. In the PR at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8 I quote the standard: 4.5.7.3 (type-bound procedure overriding) has: • Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3). 12.3.3 (Characteristics of function results): If a type parameter of a function result or a bound of a function result array is not a constant expression, the exact dependence on the entities in the expression is a characteristic So the standards is more restrictive than expression values being the same. It requires _the exact same dependence on the entities_. My reading of this is that 3*(x+1) vs 3*x+3 is right to be rejected, same for (a+b)+c vs a+(b+c). The only worrying case that I see is the one you pointed out: a+b+c vs c+b+a (without brackets). Huh, I don't see what is so different between 1) 3*(x+1) vs 3*x+3 and 2) a+b+c vs c+b+a In both cases the expressions look different at first sight, but can be transformed into each other mathematically. So I'd say they are mathematically equivalent, although the spelled-out representations of these expressions differ. I was looking at the standard, because I was not so sure myself. Here is what is written (7.1.5.2.4): Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated. Two expressions of a numeric type are mathematically equivalent if, for all possible values of their primaries, theirmathematical values are equal. So parentheses have to be respected; other than that anything is possible. This is about the evaluation of expressions though, not about the dependences on entities. The question is how you interpret the standard's formulation of exact dependence on the entities in the expression. That is the question. Naively I would have taken this to mean the *mathematical* dependence (which can be represented by different actual expressions). But I'm fine with your interpretation, too, which will make life even easier for us. Yes, my interpretation is somewhat biased towards ease of implementation. ;-) Mikael
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
without any regressions. Can anybody think of a case where the names can be identical, but the variables different? (I can't). Well, I'd say this can only happen if both variables reside in different namespaces (i.e. different modules or procedures). gfc_are_identical variables is only called from within gfc_dep_compare_expr. It makes no sense to call this function to compare expressions from different statements, unless one has carefully analyzed that no intervening assignment to the variables has taken place. Comparing across namespaces makes even less sense. So yes, I think it is enough if we compare the variable names, and document this in a commtent. Actually, on second thought, I disagree. For the original usage cases of gfc_dep_compare_expr, I'm not sure if one can guarantee the expressions to be in the same namespace. However, for the overriding checks, both expressions are guaranteed to be in *different* namespaces (namely: two different procedures). And as Mikael noted, it is crucial wether the symbols in the expressions are dummy arguments or not: 1) Dummies are guaranteed to have equal names in overridden procedures, so we can just compare names. 2) Non-dummies could have the same name, but still sit in different namespaces, so for them we really have to check for equal symbols! Here is a variant of the original test case from the PR, which will be accepted if we only check for names (but it should actually be rejected): module world implicit none type :: world_1 contains procedure, nopass :: string = w1_string end type type, extends(world_1) :: world_2 contains procedure, nopass :: string = w2_string end type contains function w1_string (m) integer, parameter :: n = 5 integer, intent(in) :: m character(n+m) :: w1_string w1_string = world end function function w2_string (m) integer, parameter :: n = 6 integer, intent(in) :: m character(n+m) :: w2_string w2_string = world2 end function end module Cheers, Janus
[PATCH, i386]: Update gcc.target/i386/sse-{22,23}.c
Hello!
2011-08-06 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/sse-22.c (dg-options): Add -march=k8.
(pragma GCC target): Add avx, fma4, lzcnt and bmi options.
* gcc.target/i386/sse-23.c (pragma GCC target): Add avx, fma4,
lzcnt and bmi options.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.target/i386/sse-23.c
===
--- gcc.target/i386/sse-23.c(revision 177507)
+++ gcc.target/i386/sse-23.c(working copy)
@@ -4,12 +4,14 @@
#include mm_malloc.h
/* Test that the intrinsics compile with optimization. All of them
- are defined as inline functions in {,x,e,p,t,s,w,a}mmintrin.h,
- xopintrin.h, lwpintrin.h, tbmintrin.h, popcntintrin.h and mm3dnow.h
- that reference the proper builtin functions. Defining away extern
- and __inline results in all of them being compiled as proper
- functions. */
+ are defined as inline functions in {,x,e,p,t,s,w,a,b,i}mmintrin.h,
+ mm3dnow.h, fma4intrin.h, xopintrin.h, abmintrin.h, bmiintrin.h,
+ tbmintrin.h, lwpintrin.h, popcntintrin.h and mm_malloc.h that
+ reference the proper builtin functions.
+ Defining away extern and __inline results in all of them being
+ compiled as proper functions. */
+
#define extern
#define __inline
@@ -145,7 +147,7 @@
#define __builtin_ia32_bextri_u32(X, Y) __builtin_ia32_bextr_u32 (X, 1)
#define __builtin_ia32_bextri_u64(X, Y) __builtin_ia32_bextr_u64 (X, 1)
-#pragma GCC target
(3dnow,sse4,sse4a,aes,pclmul,xop,abm,popcnt,lwp,tbm,fsgsbase,rdrnd,f16c)
+#pragma GCC target
(sse4a,3dnow,avx,fma4,xop,aes,pclmul,popcnt,abm,lzcnt,bmi,tbm,lwp,fsgsbase,rdrnd,f16c)
#include wmmintrin.h
#include smmintrin.h
#include mm3dnow.h
Index: gcc.target/i386/sse-22.c
===
--- gcc.target/i386/sse-22.c(revision 177507)
+++ gcc.target/i386/sse-22.c(working copy)
@@ -1,16 +1,18 @@
/* Same as sse-14, except converted to use #pragma GCC option. */
/* { dg-do compile } */
-/* { dg-options -O0 -Werror-implicit-function-declaration } */
+/* { dg-options -O0 -Werror-implicit-function-declaration -march=k8 } */
#include mm_malloc.h
-/* Test that the intrinsics compile without optimization. All of them
- are defined as inline functions in {,x,e,p,t,s,w,a}mmintrin.h,
- xopintrin.h, tbmintrin.h, lwpintrin.h, popcntintrin.h and
- mm3dnow.h that reference the proper builtin functions. Defining
- away extern and __inline results in all of them being compiled as
- proper functions. */
+/* Test that the intrinsics compile with optimization. All of them
+ are defined as inline functions in {,x,e,p,t,s,w,a,b,i}mmintrin.h,
+ mm3dnow.h, fma4intrin.h, xopintrin.h, abmintrin.h, bmiintrin.h,
+ tbmintrin.h, lwpintrin.h, popcntintrin.h and mm_malloc.h that
+ reference the proper builtin functions.
+ Defining away extern and __inline results in all of them being
+ compiled as proper functions. */
+
#define extern
#define __inline
@@ -32,6 +34,11 @@
type _CONCAT(_,func) (op1_type A, op2_type B, int const I, int const L) \
{ return func (A, B, imm1, imm2); }
+#define test_3(func, type, op1_type, op2_type, op3_type, imm) \
+ type _CONCAT(_,func) (op1_type A, op2_type B,
\
+ op3_type C, int const I)\
+ { return func (A, B, C, imm); }
+
#define test_4(func, type, op1_type, op2_type, op3_type, op4_type, imm)
\
type _CONCAT(_,func) (op1_type A, op2_type B,
\
op3_type C, op4_type D, int const I)\
@@ -39,7 +46,7 @@
#ifndef DIFFERENT_PRAGMAS
-#pragma GCC target
(mmx,3dnow,sse,sse2,sse3,ssse3,sse4.1,sse4.2,sse4a,aes,pclmul,xop,popcnt,abm,lwp,fsgsbase,rdrnd,f16c,tbm)
+#pragma GCC target
(sse4a,3dnow,avx,fma4,xop,aes,pclmul,popcnt,abm,lzcnt,bmi,tbm,lwp,fsgsbase,rdrnd,f16c)
#endif
/* Following intrinsics require immediate arguments. They
@@ -107,14 +114,18 @@
test_1x (_mm_extracti_si64, __m128i, __m128i, 1, 1)
test_2x (_mm_inserti_si64, __m128i, __m128i, __m128i, 1, 1)
-/* smmintrin.h (SSE4.1). */
-/* nmmintrin.h (SSE4.2). */
-/* Note, nmmintrin.h includes smmintrin.h, and smmintrin.h checks for the
- #ifdef. So just set the option to SSE4.2. */
+/* Note, nmmintrin.h includes smmintrin.h, and smmintrin.h
+ checks for the #ifdef. So just set the option to SSE4.2. */
#ifdef DIFFERENT_PRAGMAS
#pragma GCC target (sse4.2)
#endif
#include nmmintrin.h
+/* smmintrin.h (SSE4.2). */
+test_1 (_mm_round_pd, __m128d, __m128d, 1)
+test_1 (_mm_round_ps, __m128, __m128, 1)
+test_2 (_mm_round_sd, __m128d, __m128d, __m128d, 1)
+test_2 (_mm_round_ss, __m128, __m128, __m128, 1)
+
test_2 (_mm_blend_epi16, __m128i, __m128i, __m128i, 1)
test_2 (_mm_blend_ps, __m128, __m128, __m128, 1)
test_2 (_mm_blend_pd, __m128d, __m128d, __m128d, 1)
@@
Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.
Here is a variant of the original test case from the PR, which will be accepted if we only check for names (but it should actually be rejected): module world implicit none type :: world_1 contains procedure, nopass :: string = w1_string end type type, extends(world_1) :: world_2 contains procedure, nopass :: string = w2_string end type contains function w1_string (m) integer, parameter :: n = 5 integer, intent(in) :: m character(n+m) :: w1_string w1_string = world end function function w2_string (m) integer, parameter :: n = 6 integer, intent(in) :: m character(n+m) :: w2_string w2_string = world2 end function end module Sorry, now I have to disagree with my own earlier claims: In this example, the 'n' variables will of course be simplified to EXPR_CONSTANTs, so the name checking does not apply to them. And since the string length can not depend on local variables which are *not* constant, name checking should still be fine! Now, if Thomas says it's fine for the other cases, too, then it seems we can really get away with a much simpler patch. Hope we're not missing anything, though ... Cheers, Janus
Re: [PATCH 9/9] dwarf2cfi: Generate and connect traces.
On Thu, Jul 14, 2011 at 4:07 PM, Richard Henderson r...@redhat.com wrote: This kinda-sorta corresponds to Bernd's 007-dw2cfi patch. Certainly the same concepts of splitting the instruction stream into extended basic blocks is the same. This patch does a bit better job with the documentation. Also, I'm a bit more explicit about matching things up with the similar code from the regular CFG routines. What's missing at this point is any attempt to use DW_CFA_remember_state. I've deferred that for the moment because it's easy to test the state change code across epilogues, whereas the shrink-wrapping code is not in this tree and section switching is difficult to force. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49994 -- H.J.
Re: [PATCH, libiberty]: Check result of fwrite in test-expandargv.c
On Fri, Aug 5, 2011 at 11:51 PM, Uros Bizjak ubiz...@gmail.com wrote: My system warns during compilation of libiberty test-expandargv.c test: gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-svn/trunk/libiberty/testsuite/../../include -DHAVE_CONFIG_H -I.. -o test-expandargv \ ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c ../libiberty.a ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c: In function ‘writeout_test’: ../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c:211: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result Attached patch fixes this warning. 2011-08-05 Uros Bizjak ubiz...@gmail.com * testsuite/test-expandargv.c (writeout_test): Check result of fwrite. Tested on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu. I have committed this patch as obvious. Please also note, that size and nitems arguments to fwrite were reversed. Uros.
