__builtin_return_address for ARM
Hello, currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? Up to now I only had a quick glance at gcc sources and after that I'm not sure if I even find the place where to put an implementation, so any help is welcome. Best regards Uwe [1] at least in gcc 4.3.2 that I'm using. [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/52061/focus=52116 -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions| http://www.pengutronix.de/ |
Re: __builtin_return_address for ARM
Uwe Kleine-König wrote: Hello, currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? My personal opinion is that Mikael Pettersson is right, but since the damage is done why not extend it to more architectures. I am not an ARM maintainer though. Paolo
Re: __builtin_return_address for ARM
Uwe Kleine-König wrote: currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? The old APCS, if I recall correctly, required a frame pointer, so __builtin_return_address(N) was easy. Up to now I only had a quick glance at gcc sources and after that I'm not sure if I even find the place where to put an implementation, so any help is welcome. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Andrew.
Re: __builtin_return_address for ARM
On Wednesday 25 February 2009, Andrew Haley wrote: Uwe Kleine-König wrote: currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? The old APCS, if I recall correctly, required a frame pointer, so __builtin_return_address(N) was easy. One minor exception: Thumb code generally doesn't have a frame pointer chain either, even on old-abi targets. In general it's impossible to make __builtin_return_address(N) to work for N0. Up to now I only had a quick glance at gcc sources and after that I'm not sure if I even find the place where to put an implementation, so any help is welcome. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. The short story is that on modern ARM targets[1] there is no standard frame layout. It is not possible to do backtraces without using additional unwind tables. Current arm-linux kernels use a special set of options to allow this under most circumstances. However this often incurs a significant performance and code size hit, and isn't supported at all when you switch to Thumb mode. Paul [1] I believe the same is also true for some other targets, e.g. MIPS.
Re: Please block henry2000 from the wiki
On Tue, 24 Feb 2009, Steven Bosscher wrote: Can someone *please* ban this nutcase from the wiki? There is almost weekly spam added to the wiki from this account. Thanks, Let me forward this to the overseers team... Gerald
Re: __builtin_return_address for ARM
On Wed, 2009-02-25 at 12:27 +, Paul Brook wrote: In general it's impossible to make __builtin_return_address(N) to work for N0. In any situation where you need to look beyond the current frame needs agreement as to how the data required can be found. That's going to have an impact somehow compared with not permitting such access (if a compiler knows that its frame is private then it can make all kinds of optimizations that would be unacceptable otherwise). There are essentially two ways of exposing the information needed here: 1) You can lay out every frame according to an agreed model 2) You can provide every frame with a description that can be interpreted to recover the required information. Neither is free. Case 1 is the worst since it severely impacts performance for code even if it never makes use of your feature. Case 2 is less bad in performance terms, but has a major impact on space in that the descriptions can be non-trivial. IMO any solution based on case 1 is unacceptable -- why should I penalise my code for some feature that you want, but I'm completely uninterested in? Case 2 is only acceptable if constructed in such a way that the additional information can be automatically discarded if it is not required -- again, why should I penalise my code size numbers for a feature I don't want. In statically linked images it might be possible to determine that the additional unwind information is unneeded and simply throw it away during linking, but you can't do that in a shared library environment, so we're back to the original sticking point: who gave you the right to impose such a levy on my code? Finally, gcc for ARM conforms to the ABI for the ARM Architecture -- that says what can and can't be assumed when linking code built from other tool chains. If you want a feature like this to work you'll need to persuade the other toolchain developers to co-operate -- I think they are extremely unlikely to be interested R.
real_format_for_mode / Porting GCC on a new arch
Hi, I would like to know more about REAL_MODE_FORMAT and real_format_for_mode. I'm sorry because I already posted this email in gcc-help mailing-list but there was no answer and maybe its right place is here ? I am working on a port of GCC. The new xgcc generated crashes this way : Program received signal SIGSEGV, Segmentation fault. builtin_define_float_constants (name_prefix=0x83fcaf9 FLT, fp_suffix=0x8419523 F, fp_cast=0x84109dd %s, type=0xb7c0a410) at ../../gcc-4.3.3/gcc/c-cppbuiltin.c:108 108 gcc_assert (fmt-b != 10); because fmt = 0. This fmt results of fmt = REAL_MODE_FORMAT (TYPE_MODE (type)); and REAL_MODE_FORMAT is defined this way : #define REAL_MODE_FORMAT(MODE) \ (real_format_for_mode[DECIMAL_FLOAT_MODE_P (MODE) \ ? ((MODE - MIN_MODE_DECIMAL_FLOAT) \ + (MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1)) \ : (MODE - MIN_MODE_FLOAT)]) But I did not find definition for real_format_for_mode, just an extern in real.h (nothing in real.c) : extern const struct real_format * real_format_for_mode[MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1 + MAX_MODE_DECIMAL_FLOAT - MIN_MODE_DECIMAL_FLOAT + 1]; Should I include an implementation of real_format_for_mode in my target.c ? If I should, how can I do that ? If not, how to avoid this crash ? Any idea ? Thank you. Florent
Re: real_format_for_mode / Porting GCC on a new arch
On Wed, Feb 25, 2009 at 4:43 PM, Florent DEFAY spira.inhabit...@gmail.com wrote: Hi, I would like to know more about REAL_MODE_FORMAT and real_format_for_mode. I'm sorry because I already posted this email in gcc-help mailing-list but there was no answer and maybe its right place is here ? I am working on a port of GCC. The new xgcc generated crashes this way : Program received signal SIGSEGV, Segmentation fault. builtin_define_float_constants (name_prefix=0x83fcaf9 FLT, fp_suffix=0x8419523 F, fp_cast=0x84109dd %s, type=0xb7c0a410) at ../../gcc-4.3.3/gcc/c-cppbuiltin.c:108 108 gcc_assert (fmt-b != 10); because fmt = 0. This fmt results of fmt = REAL_MODE_FORMAT (TYPE_MODE (type)); and REAL_MODE_FORMAT is defined this way : #define REAL_MODE_FORMAT(MODE) \ (real_format_for_mode[DECIMAL_FLOAT_MODE_P (MODE) \ ? ((MODE - MIN_MODE_DECIMAL_FLOAT) \ + (MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1)) \ : (MODE - MIN_MODE_FLOAT)]) But I did not find definition for real_format_for_mode, just an extern in real.h (nothing in real.c) : extern const struct real_format * real_format_for_mode[MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1 + MAX_MODE_DECIMAL_FLOAT - MIN_MODE_DECIMAL_FLOAT + 1]; Should I include an implementation of real_format_for_mode in my target.c ? If I should, how can I do that ? If not, how to avoid this crash ? Any idea ? It is in the generated file insn-modes.c generated by genmodes.c from machmode.def. Richard. Thank you. Florent
query automaton
Hello, Some time ago I asked a question regarding the possibility to schedule an operation on alternative functional units (FUs) AND depending on the chosen FUs to generate a dedicated assembly mnemonic. To give a simple example suppose I have a move operation that can be issued on one of the 2 different FUs: (define_reservation si_move(q_salu, r_salu_rp,r_salu + r_salu_r_wp) |(q_smac, nothing, r_smac + r_smac_wp) ,nothing* 3) Depending on the occupied FUs one of the following assembly instructions are generated: move_salu or move_smac. To find out which FUs were occupied I defined 2 query_cpu_unit-s: (define_query_cpu_unit q_salu aut1) (define_query_cpu_unit q_smac aut1) ,which further on (during the sched2 hook TARGET_SCHED_DFA_NEW_CYCLE) are used to find out which of the 2 alternative reservations the automaton has taken. Based on this decision I add some information within the insn rtx which later on is used to dump move_salu or move_smac. This approach was successful as long as the units claimed by si_move belong to one and the same automaton ( i.e., q_salu, q_smac, r_salu_rp, r_salu, r_salu_r_wp, r_smac, r_smac_wp belong to aut1). If I try to split aut1 into (lets say 2) automatons I get generated incorrect code (i.e., the choice of choosing the proper unit is not correct anymore.) QUESTION: Is there such constraint that the units part of the alternatives of a reservation must belong to the same automaton?
Re: [Ada] Wrong code in gcc/ada/a-teioed.adb causing FAIL of ACATS ?cxf3a01 on mipsel and ia64
On Wed, 2009-02-18 at 10:23 +0100, Laurent GUERBY wrote: On Wed, 2009-02-18 at 08:56 +0100, Arnaud Charlet wrote: OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on mainline, except regressions (I hope stage 1 will open soon, since we have monthes of backlog of various fixes and new development blocked right now which will be painful to merge). If the ACATS test fails on ia64-linux, that's a regression from 4.3.x. OK, that's a little surprising, but if it's indeed a confirmed regression, then it's fine to commit now. I didn't put a regression tag because I don't have access to ia64-linux but according to Andreas Schwab testresults ACATS was clean on ia64 4.3: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01606.html And was failing all cxf3a0N tests back in november: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01831.html Currently they do not fail on ia64 4.4 but I guess any unrelated commit can make them fail again. Also formally this bug has security implications since we're overwritting memory, so may be I should backport it. Let me know if you think it's still okay for 4.4 and if it's okay for 4.3 backport commit (after testing there of course). After checking cxf3a01 showed up here: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02370.html So I went ahead and commited the buffer overflow fix on 4.4. If it shows up on 4.3 too I'll backport. Laurent
Re: __builtin_return_address for ARM
Paul Brook wrote: On Wednesday 25 February 2009, Andrew Haley wrote: In general it's impossible to make __builtin_return_address(N) to work for N0. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 by libcalling into the unwinder for you? Obviously this would still have to return NULL at runtime when you're running on a DW2 target without any EH frame data present in memory (and I guess it wouldn't work on SjLj targets either), but wouldn't it still be a nice convenience feature for users? cheers, DaveK
Is a Better Warning for this Stupid Mistake?
Hi, I made a stupid typo and accidentally included an unprotected file from itself. The error message generated by gcc surprised me and I wondered if there was a better alternative. $ cat recursive_include.c #include recursive_include.c $ gcc -c recursive_include.c from recursive_include.c:1: recursive_include.c:1:31: error: #include nested too deeply $ gcc -c recursive_include.c 21 | wc -l 200 Thanks. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Fwd: Constant folding and Constant propagation
Dear all, I was working on the machine description so I was postponing a bit this problem but now I have a bit more time on my hands to handle it. I'm starting to look at the various links and code you've provided me and will keep you posted if I make any headway or not ;-). For the GCC port I work on, I have fixed this by weighing the rtx_cost of propagating a register copy Vs propagating the constant into an insn. I have an initial patch for this problem. Do you have a link to that patch? So that I can see if it applies for me ? Thanks, Jc On Tue, Feb 10, 2009 at 2:25 PM, Rahul Kharche ra...@icerasemi.com wrote: I am looking at a related problem in GCSE, GCC 4.3 whereby constants are propagated to their use irrespective of the final instruction cost of generating them (machine cycles or instruction count). Global constant propagation effectively voids common expressions that form large constants, identified by global CSE. This is especially true of SYMBOl_REF constants like section-anchors generated while indexing global arrays. For the GCC port I work on, I have fixed this by weighing the rtx_cost of propagating a register copy Vs propagating the constant into an insn. I have an initial patch for this problem. Rahul Vijay Kharche
gcc-4.2-20090225 is now available
Snapshot gcc-4.2-20090225 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090225/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 144437 You'll find: gcc-4.2-20090225.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090225.tar.bz2 C front end and core compiler gcc-ada-4.2-20090225.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090225.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090225.tar.bz2 C++ front end and runtime gcc-java-4.2-20090225.tar.bz2 Java front end and runtime gcc-objc-4.2-20090225.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090225.tar.bz2The GCC testsuite Diffs from 4.2-20090218 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Fwd: Pseudo-templates
Dear all, We are two students in a Compiler Design course who have been assigned to work on a gcc beginners project. We have chosen the project on making pseudo-templated containers, and we had some questions about the semantics you want from them. The gcc page specifically mentioned splay trees and hash tables, so we will ask about those. The goal of the project was stated to be the elimination of abstraction penalties. The hash table and splay tree both store entries by pointer (except that splay tree can cast ints to the pointer and back out). Would you prefer a generic container that held items by value? We could do this, but it would break code that expects aliases to be preserved. We are currently working under the assumption that it is acceptable for all of our function-like macros to take the type of the stored elements. Do you agree? Is it okay for lookup function macros to take the type they are looking up? If we can take the type, we can make the semantics of returning pointers much more elegant. Thanks for your help, Patrick Moran Walter Maguire
Announce: MPFR 2.4.1 is released
After a buffer overflow has been found (and fixed) in the mpfr_snprintf and mpfr_vsnprintf functions of MPFR 2.4.0, it has been decided to release MPFR 2.4.1 immediately. It is available for download from the MPFR web site: http://www.mpfr.org/mpfr-2.4.1/ The MD5's: 22402995cf2496d8faea42c8da02ce1f mpfr-2.4.1.tar.lzma c5ee0a8ce82ad55fe29ac57edd35d09e mpfr-2.4.1.tar.bz2 a70bbde2a23d82e8f3314d4293500ae4 mpfr-2.4.1.tar.gz 63c1ebc19f720853c75e5bef22405490 mpfr-2.4.1.zip Changes from version 2.4.0 to version 2.4.1: - Security fix in mpfr_snprintf and mpfr_vsnprintf (buffer overflow). - Configure: new checks for length modifiers hh and ll (new in C99) as hh is absent on alpha-OSF1-V5. - Miscellaneous corrections in the MPFR manual. In particular, mpfr_inits, mpfr_inits2, mpfr_clears and MPFR_DECL_INIT have been in the public API since MPFR 2.4.0. You can send success and failure reports to m...@loria.fr, and give us the canonical system name as returned by the config.guess script, the processor and compiler version, in order to complete the Platforms Known to Support MPFR section of the MPFR 2.4.1 web page. Regards, -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
[Bug target/39291] _Unwind_Backtrace fails.
--- Comment #3 from pluto at agmk dot net 2009-02-25 08:24 --- (In reply to comment #2) I get this with your testcase on mingw32, DW@ build: GNU C (GCC) version 4.4.0 20090221 (experimental) (mingw32) i have a gcc/dw2 configured with: Using built-in specs. Target: i486-pc-mingw32 Configured with: ../configure --target=i486-pc-mingw32 --with-arch=i486 --prefix=/local/devel/toolchain44/i486-pc-mingw32.host64 --with-sysroot=/local/devel/toolchain44/i486-pc-mingw32.host64 --libdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib --libexecdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib --with-slibdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib --with-gmp-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include --with-gmp-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib --with-mpfr-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include --with-mpfr-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib --disable-multilib --disable-nls --disable-libgomp --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-pic --enable-c99 --enable-long-long --disable-win32-registry --enable-threads=win32 --disable-sjlj-exceptions --enable-shared --enable-__cxa_atexit --enable-languages=c,c++ --disable-symvers --with-pic --with-long-double-128 --disable-cld --disable-bootstrap Thread model: win32 gcc version 4.4.0 20090220 (experimental) (GCC) gcc -fexceptions -g u.c foo:enter bar:enter zoo:enter boom! signalHandler:enter lookupSymbol: 00401407 lookupSymbol: 00401232 signalHandler:longjmp zoo:exit bar:exit foo:exit alive! could you attach a precompiled .exe? i'll check it on my winxp64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 08:52 --- Sooo - what is the content of the .optimized dump? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug target/37520] [4.4 Regression] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-25 08:57 --- Let's make this P1 until we are sure it is not an ABI problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug middle-end/39298] New: Optimize away only set but not used variable
In the following Fortran program, the variable foo is never used, it is only set. Result: Using gfortran -O3, foo is not optimized away. Expected: foo is optimized away as it happens with ifort -O2. program a implicit none integer*8 it,two parameter(it=1073741824,two=2) complex foo(it*two-1) foo(10)=1. write(*,*) '' end program a -- Summary: Optimize away only set but not used variable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 09:43 ---
Is there a reason the Fortran frontend gives function local variables static
storage duration?
a ()
{
struct __st_parameter_dt dt_parm.1;
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
static complex(kind=4) foo[2147483647];
bb 2:
_gfortran_set_options (8, options.0);
foo[9] = __complex__ (1.0e+0, 0.0);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-25 09:43:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 09:51 --- It works with it == 1024 in which case foo is not static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work
--- Comment #11 from andreasmeier80 at gmx dot de 2009-02-25 10:33 --- The target milestone 4.0.4 is wrong -- andreasmeier80 at gmx dot de changed: What|Removed |Added CC||andreasmeier80 at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-25 10:35 --- I did some testing with sunf95, icc and ifort. sunf95 also puts the variable in .bss as gfortran does, while ifort puts it on the stack (unless explicitly declared as static [SAVE]). If the variable is static, neither of the compilers optimizes it away. a) Why are static variables not optimized away? (Not even in main()/MAIN_?) b) Is there something what one could do to get the advantage of not having huge variables on the stack but still allowing to optimize the variable away? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-25 10:21 --- Is there a reason the Fortran frontend gives function local variables static storage duration? For huge arrays, there is a problem if the memory is allocated on the stack, as one quickly hits stack-size limits. Thus gfortran puts large local arrays in static memory, except when a procedure can be called recursively/simultaneously (RECURSIVE attribute, -frecursive, -fopenmp). The size for which this happens is controlled by -fmax-stack-var-size=n. Actually, I don't quite see why the static matters: As local variable it cannot be accessed from elsewhere and if it is not accessed in the procedure ... Additionally, C's main() and Fortran's PRORGRAM (= MAIN__) are special because they are only called once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug tree-optimization/39299] New: wrong PTA for structure copies
At -O2 -fno-tree-sra we compute y.p as pointing to nothing. Which causes
the abort to trigger on alias-improvements branch.
struct X
{
long l1;
struct Y
{
long l2;
int *p;
} y;
};
int i;
int foo (struct X *x)
{
struct Y y = x-y;
*y.p = 0;
i = 1;
return *y.p;
}
extern void abort (void);
int main()
{
struct X x;
x.y.p = i;
if (foo(x) != 1)
abort ();
return 0;
}
--
Summary: wrong PTA for structure copies
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39299
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-25 11:21 --- Optimizing dead local static variables requires special handling which probably is not thought to be worth the trouble. If the variable is unused the programmer can as well remove it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug tree-optimization/39300] New: vectorizer confused by predictive commoning
The loop in this test is not vectorized if either PRE or predictive commoning is active: % cat vecttest2.f subroutine Bench_StaggeredLeapfrog2( cctk_dim,XADM_curv_stag0, ADM_kzz_stag,lgxx,nx) implicit none INTEGER cctk_dim INTEGER XADM_curv_stag0 REAL*8 ADM_kzz_stag(XADM_curv_stag0) integer :: i integer :: nx REAL*8,DIMENSION(cctk_dim):: lgxx do i=2,nx-1 ADM_kzz_stag(i) = ADM_kzz_stag(i)+lgxx(i)+lgxx(i-1)+lgxx(i+1) end do end subroutine Bench_StaggeredLeapfrog2 % gfortran -c -O3 -g -ffast-math -ftree-vectorizer-verbose=2 vecttest2.f vecttest2.f:11: note: not vectorized: unsupported use in stmt. vecttest2.f:12: note: not vectorized: unsupported use in stmt. % add -fno-tree-pre -fno-predictive-commoning to above command: vecttest2.f:11: note: LOOP VECTORIZED. % add only -fno-tree-pre (so predictive commoning is active): vecttest2.f:11: note: LOOP VECTORIZED. vecttest2.f:12: note: not vectorized: unsupported use in stmt. The one vectorized loop in case it mentions two of them is the tail loop for the one produced by predictive commoning. That one doesn't contain any loop carried values. Somehow the vectorizer doesn't like the PHI nodes in the loop created by predictive commoning. This testcase comes from 436.cactusADM, where it's very important to vectorize a certain inner loop, and this (PRE and predcom) is one reason this doesn't happen already. -- Summary: vectorizer confused by predictive commoning Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #16 from bonzini at gnu dot org 2009-02-25 12:18 ---
The upcoming C++0x memory model forbids this; see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html (Concurrency
memory model compiler consequences). But it says that this is acceptable
instead:
tmp = var;
modified = false;
for (i = 0; i 100; i++)
{
if (i x)
tmp = i, modified = true;
}
if (modified)
var = tmp;
I think the bug can be confirmed, can't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884
--- Comment #5 from pault at gcc dot gnu dot org 2009-02-25 13:05 --- Steve, At this stage in the 4.4 release process, I think my patch is too risky. I've only done some limited testing. This should probably be considered a 4.5 patch. Should I apply mine, with a check that the expression is constant? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39292
[Bug tree-optimization/39299] wrong PTA for structure copies
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 13:08 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-25 13:08:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39299
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-25 13:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-02-25 13:25:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
Re: [Bug middle-end/39298] Optimize away only set but not used variable
Sent from my iPhone
On Feb 25, 2009, at 1:43 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25
09:43 ---
Is there a reason the Fortran frontend gives function local
variables static
storage duration?
Yes, it is larger than the threshhold. Remember fortran has no
recursive functions except for the ones which marked as such.
a ()
{
struct __st_parameter_dt dt_parm.1;
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
static complex(kind=4) foo[2147483647];
bb 2:
_gfortran_set_options (8, options.0);
foo[9] = __complex__ (1.0e+0, 0.0);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-25 09:43:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug middle-end/39298] Optimize away only set but not used variable
--- Comment #6 from pinskia at gmail dot com 2009-02-25 13:37 ---
Subject: Re: Optimize away only set but not used variable
Sent from my iPhone
On Feb 25, 2009, at 1:43 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25
09:43 ---
Is there a reason the Fortran frontend gives function local
variables static
storage duration?
Yes, it is larger than the threshhold. Remember fortran has no
recursive functions except for the ones which marked as such.
a ()
{
struct __st_parameter_dt dt_parm.1;
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
static complex(kind=4) foo[2147483647];
bb 2:
_gfortran_set_options (8, options.0);
foo[9] = __complex__ (1.0e+0, 0.0);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-25 09:43:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
[Bug tree-optimization/39300] vectorizer confused by predictive commoning
--- Comment #1 from matz at gcc dot gnu dot org 2009-02-25 13:53 --- For reference intel fortran (11.0) produces three loops, one where it uses predictive commoning (that is used when there are only few iterations): ..B1.7: # Preds ..B1.6 movsd 8(%r8), %xmm1 #13.52 movsd (%r8), %xmm0 #13.52 # LOE rax rdx rcx rbx rbp rsi rdi r8 r9 r12 r13 r14 r15 xmm0 xmm1 ..B1.8: # Preds ..B1.8 ..B1.7 movaps%xmm1, %xmm2 #13.33 movsd 16(%r8,%rdi,8), %xmm3 #13.52 addsd %xmm3, %xmm2 #13.33 addsd %xmm0, %xmm2 #13.41 movaps%xmm1, %xmm0 #14.7 movaps%xmm3, %xmm1 #14.7 addsd 8(%rdx,%rdi,8), %xmm2 #13.9 movsd %xmm2, 8(%rcx,%rdi,8) #13.9 incq %rdi #14.7 cmpq %rax, %rdi#14.7 jl..B1.8# Prob 82% #14.7 And two others which are vectorized (plus four/eight times unrolled), but do _not_ use something like predictive commoning (i.e. no cross iteration values). Both loops are just versions of each other, one for aligned destinations and the other for unaligned. The aligned variant is this: ..B1.15:# Preds ..B1.10 ..B1.15 movsd 8(%rdx,%rax,8), %xmm1 #13.18 movhpd16(%rdx,%rax,8), %xmm1#13.18 movsd 8(%r8,%rax,8), %xmm0 #13.34 movhpd16(%r8,%rax,8), %xmm0 #13.34 movsd 24(%rdx,%rax,8), %xmm4#13.18 movhpd32(%rdx,%rax,8), %xmm4#13.18 movsd 24(%r8,%rax,8), %xmm2 #13.34 movhpd32(%r8,%rax,8), %xmm2 #13.34 movsd 40(%rdx,%rax,8), %xmm7#13.18 movhpd48(%rdx,%rax,8), %xmm7#13.18 movsd 40(%r8,%rax,8), %xmm5 #13.34 movhpd48(%r8,%rax,8), %xmm5 #13.34 movsd 56(%rdx,%rax,8), %xmm10 #13.18 movhpd64(%rdx,%rax,8), %xmm10 #13.18 movsd 56(%r8,%rax,8), %xmm8 #13.34 movhpd64(%r8,%rax,8), %xmm8 #13.34 addpd %xmm0, %xmm1 #13.33 addpd (%r8,%rax,8), %xmm1 #13.41 addpd %xmm2, %xmm4 #13.33 addpd %xmm5, %xmm7 #13.33 addpd %xmm8, %xmm10 #13.33 movaps16(%r8,%rax,8), %xmm3 #13.52 addpd %xmm3, %xmm1 #13.9 movaps32(%r8,%rax,8), %xmm6 #13.52 movaps48(%r8,%rax,8), %xmm9 #13.52 movaps%xmm1, 8(%rcx,%rax,8) #13.9 addpd %xmm3, %xmm4 #13.41 addpd %xmm6, %xmm4 #13.9 movaps%xmm4, 24(%rcx,%rax,8)#13.9 addpd %xmm6, %xmm7 #13.41 addpd %xmm9, %xmm7 #13.9 movaps%xmm7, 40(%rcx,%rax,8)#13.9 addpd %xmm9, %xmm10 #13.41 addpd 64(%r8,%rax,8), %xmm10#13.9 movaps%xmm10, 56(%rcx,%rax,8) #13.9 addq $8, %rax #14.7 cmpq %r9, %rax #14.7 jl..B1.15 # Prob 82% #14.7 Not most optimal, due to not using the cross-iteration values to save two loads per iteration. But still much better than what GCC uses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug tree-optimization/39300] vectorizer confused by predictive commoning
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 13:56 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-02-25 13:56:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug c/39301] New: ICE in register_overhead, at bitmap.c:115
With this compiler:
[luc...@descartes gambc-v4_4_1-devel]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64
Thread model: posix
gcc version 4.4.0 20090224 (experimental) [trunk revision 144414] (GCC)
with compiler.i found at
http://www.math.purdue.edu/~lucier/bugzilla/8
and this command line:
[luc...@descartes gambc-v4_4_1-devel]$ gdb
/pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1
(gdb) run -I../include -Wall -W -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math
-fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common compiler.i
one gets an ICE
Starting program:
/pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1
-I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1
-fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common compiler.i
btowc wctob mbrlen {GC 5504k - 3345k} {GC 5325k - 4387k} code_size
___H__20_compiler_2e_o1 {GC 202396k - 113348k} ___init_proc
20_compiler_2e_o1
Analyzing compilation unit
{GC 182571k - 135708k}Performing interprocedural optimizations
visibility early_local_cleanups {GC 237987k - 236439k} summary generate
inline static-var pure-constAssembling functions:
code_size ___init_proc 20_compiler_2e_o1 ___H__20_compiler_2e_o1 {GC
349654k - 288661k} {GC 406235k - 272087k}
compiler.c: In function ___H__20_compiler_2e_o1:
compiler.c:322876: internal compiler error: in register_overhead, at
bitmap.c:115
I'm sorry the test case is enormous, but it runs in about a GB of RAM. I also
haven't been able to figure out how to use gdb properly in this mixed
ppc32/ppc64 environment.
--
Summary: ICE in register_overhead, at bitmap.c:115
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
[Bug other/39302] New: [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd
Before patches from ARC International (UK) Ltd can be reviewed, it must be verified that a valid copyright assignment is on file at the FSF. This blocks a number of bugs where patches are available, but cannot be reviewed. -- Summary: [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39302
[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-25 14:07 ---
Simpler C testcase:
float res[1024], data[1024];
void foo(void)
{
int i;
float tmp = data[0];
for (i = 1; i 1024; ++i)
{
float tmp2 = data[i];
res[i] = tmp + tmp2;
tmp = tmp2;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE
--- Comment #4 from irar at il dot ibm dot com 2009-02-25 14:08 --- Looks similar to PR 35229. We get here: # pre.1 = PHI D.1, D.2 .. load D.2 D.3 = D.2 + pre.1 + ... store D.3 -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug c/39301] ICE in register_overhead, at bitmap.c:115
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 14:10 ---
/* Store information about each particular bitmap. */
struct bitmap_descriptor
{
const char *function;
const char *file;
int line;
int allocated;
int created;
int peak;
int current;
int nsearches;
};
I guess we simply overflow current. Using HOST_WIDEST_INT for the counters
would be appropriate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 14:12 ---
Indeed. Proper testcase:
float res[1024], data[1024];
void foo(void)
{
int i;
float tmp = data[0];
for (i = 1; i 1024; ++i)
{
float tmp2 = data[i];
res[i] = tmp + tmp2;
tmp = tmp2;
}
}
manually optimized from
res[i] = data[i] + data[i-1];
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
OtherBugsDependingO||39300
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-25 14:12:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35229
[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 14:33 ---
Or like the following, which is just a bunch of reductions of two elements
float data[1024];
void foo(void)
{
int i;
for (i = 1; i 1024; ++i)
data[i] = data[i] + data[i-1];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35229
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-25 14:37 ---
(In reply to comment #1)
Sooo - what is the content of the .optimized dump?
;; Function foo (foo)
Analyzing Edge Insertions.
foo (int len, int v)
{
long unsigned int D.1255;
long unsigned int ivtmp.14;
bb 2:
if (len 0)
goto bb 3;
else
goto bb 5;
bb 3:
ivtmp.14 = (long unsigned int) a[0];
D.1255 = ((long unsigned int) a + 2) + (long unsigned int) ((unsigned int)
le
n + 4294967295) * 2;
bb 4:
MEM[index: ivtmp.14] = (short int) (short int) v;
ivtmp.14 = ivtmp.14 + 2;
if (ivtmp.14 != D.1255)
goto bb 4;
else
goto bb 5;
bb 5:
return a[0];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-25 14:41 --- Note index: again, bo. I thought I got rid of all those. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #4 from rguenther at suse dot de 2009-02-25 14:48 ---
Subject: Re: [4.4 Regression]
gcc.dg/tree-ssa/loop-31.c
On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote:
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-25 14:37
---
(In reply to comment #1)
Sooo - what is the content of the .optimized dump?
;; Function foo (foo)
Analyzing Edge Insertions.
foo (int len, int v)
{
long unsigned int D.1255;
long unsigned int ivtmp.14;
bb 2:
if (len 0)
goto bb 3;
else
goto bb 5;
bb 3:
ivtmp.14 = (long unsigned int) a[0];
D.1255 = ((long unsigned int) a + 2) + (long unsigned int) ((unsigned int)
le
n + 4294967295) * 2;
This likely used to be folded to a[len], but the addressing-mode
is still what it is supposed to be. Can you attach the dump with
the patch reverted as well?
bb 4:
MEM[index: ivtmp.14] = (short int) (short int) v;
ivtmp.14 = ivtmp.14 + 2;
if (ivtmp.14 != D.1255)
goto bb 4;
else
goto bb 5;
bb 5:
return a[0];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-25 14:53 ---
Revision 144404 gave:
;; Function foo (foo)
Analyzing Edge Insertions.
foo (int len, int v)
{
short int * D.1254;
short int * ivtmp.14;
bb 2:
if (len 0)
goto bb 3;
else
goto bb 5;
bb 3:
D.1254 = a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1)
* 2;
ivtmp.14 = a[0];
bb 4:
MEM[base: ivtmp.14] = (short int) (short int) v;
ivtmp.14 = ivtmp.14 + 2;
if (ivtmp.14 != D.1254)
goto bb 4;
else
goto bb 5;
bb 5:
return a[0];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #6 from rguenther at suse dot de 2009-02-25 15:01 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote: --- Comment #5 from hjl dot tools at gmail dot com 2009-02-25 14:53 --- Revision 144404 gave: Is the assembly different? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-25 15:09 --- Revision 144405 gave: .text .align 16 .global foo# .type foo#, @function .proc foo# foo: .prologue .body cmp4.ge p6, p7 = 0, r32 (p6) br.cond.spnt .L2 addl r14 = @ltoffx(a#), r1 ;; ld8.mov r14 = [r14], a# adds r16 = -1, r32 ;; addp4 r16 = r16, r0 addl r15 = @gprel(.LC0), gp ;; ld8 r15 = [r15] ;; shladd r15 = r16, 1, r15 .L3: st2 [r14] = r33, 2 ;; cmp.ne p6, p7 = r15, r14 (p6) br.cond.sptk .L3 .L2: addl r14 = @ltoffx(a#), r1 ;; ld8.mov r14 = [r14], a# ;; ld2 r8 = [r14] br.ret.sptk.many b0 ;; .endp foo# Revision 144404 gave: .proc foo# foo: .prologue .save ar.lc, r2 mov r2 = ar.lc .body cmp4.ge p6, p7 = 0, r32 (p6) br.cond.spnt .L2 adds r15 = -1, r32 ;; addp4 r15 = r15, r0 ;; adds r15 = 1, r15 addl r14 = @ltoffx(a#), r1 ;; ld8.mov r14 = [r14], a# ;; shladd r15 = r15, 1, r14 ;; sub r15 = r15, r14 ;; adds r15 = -2, r15 ;; shr.u r15 = r15, 1 ;; mov ar.lc = r15 .L3: st2 [r14] = r33, 2 ;; br.cloop.sptk.few .L3 .L2: addl r14 = @ltoffx(a#), r1 ;; ld8.mov r14 = [r14], a# ;; ld2 r8 = [r14] mov ar.lc = r2 br.ret.sptk.many b0 ;; .endp foo# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-25 15:52 --- An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01171.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00961.html|02/msg01171.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug target/39303] New: ARC port does not support ARCompact architecture
The ARC port that is currently in the FSF GCC does not support the ARCompact architecture, which is used by the current and ARC chips ARC600 and ARC700, and by the already superceded ARCtangent-A5. -- Summary: ARC port does not support ARCompact architecture Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39303
[Bug fortran/39304] New: ICE on module compilation
I am trying to compile a module for automatic differentiation. The file is called auto_deriv.f90 and is distributed by the journal Computer Physics Communications at http://www.cpc.cs.qub.ac.uk/summaries/ADLS_v1_0.html . However, when trying to compile this with gfortran -c auto_deriv.f90 I get: In file auto_deriv.f90:2757 END MODULE deriv_class 1 Internal Error at (1): spec_dimen_size(): Bad dimension I have absolutely no idea why this happens. Just in case it is helpful there is an HTML version of the associated paper available online at http://tccc.iesl.forth.gr/~farantos/po_cpc/auto_deriv.html -- Summary: ICE on module compilation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Huub dot van-Dam at stfc dot ac dot uk GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug fortran/39304] ICE on module compilation
--- Comment #1 from Huub dot van-Dam at stfc dot ac dot uk 2009-02-25 16:02 --- Created an attachment (id=17358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17358action=view) The file that fails to compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug fortran/39304] ICE on module compilation
--- Comment #2 from Huub dot van-Dam at stfc dot ac dot uk 2009-02-25 16:03 --- Created an attachment (id=17359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17359action=view) A tiny sample program that uses auto_deriv.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #18 from davids at webmaster dot com 2009-02-25 16:06 --- This is a real bug. There is simply no way to write correct threaded code if the compiler is free to read a variable and write it back when the code didn't specifically tell it to. Optimizations on threaded code cannot add a write to a variable unless they can prove no other thread could know the location of the variable. (It's local, it's address has never been passed to a function, and so on.) In any event, the last time I looked into this, it seemed that such 'optimizations' were typically pessimizations on multi-threaded code anyway, as they added expensive cache misses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #19 from dnovillo at google dot com 2009-02-25 16:12 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On Wed, Feb 25, 2009 at 11:06, davids at webmaster dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #18 from davids at webmaster dot com  2009-02-25 16:06 --- This is a real bug. There is simply no way to write correct threaded code if the compiler is free to read a variable and write it back when the code didn't specifically tell it to. Yes. Unless we build an actual concurrent data flow and adapt the optimizers for these programs, we will never get it right. The best approach in these cases is to tell the optimizers to back off completely. After all the code has completely different semantics from what they are ready to handle. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug fortran/39304] ICE on module compilation
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-25 16:23 --- Confirmed on powerpc-apple-darwin9 (trunk rev. 144372, 4.2.3 and 4.3.3). g95 gives the following warning (lines 477, 488, 499, 510, 521, 532, and 543) Warning (158): INTENT(OUT) variable 'res' at (1) is never set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug ada/39172] libada parsing of multilib options
--- Comment #2 from schwab at suse dot de 2009-02-25 16:43 --- The problem seems to be that the AWK makefile variable is not properly passed down to submakes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
[Bug tree-optimization/39305] New: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling
For some simple loops with early exits, like libgcc2.c:__gcc_bcmp, copy_loop_headers copies not only the header, but also the loop body, and thus disables doloop optimizations. -- Summary: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 39302 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39305
[Bug ada/39172] libada parsing of multilib options
--- Comment #3 from schwab at suse dot de 2009-02-25 16:57 --- Created an attachment (id=17360) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17360action=view) Candidate patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
[Bug ada/39172] libada parsing of multilib options
--- Comment #4 from schwab at suse dot de 2009-02-25 16:58 --- Can you please try out the attached patch? -- schwab at suse dot de changed: What|Removed |Added Status|ASSIGNED|WAITING GCC host triplet|i686-pc-linux-gnu | GCC target triplet|m68k-rtems4.10 |m68k-*.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
[Bug middle-end/39274] internal compiler error: in check_cfg, at haifa-sched.c, var-tracking
--- Comment #2 from sergei_lus at yahoo dot com 2009-02-25 17:00 --- Thank you for the suggestion, but... I use schedule_ebbs in machine dependent reorg, and I do call compute_bb_for_insn before it. CFG is messed up before I get there... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39274
[Bug ada/39172] libada parsing of multilib options
--- Comment #6 from joel at gcc dot gnu dot org 2009-02-25 17:04 --- Can you include the generated files please? I do not have autoconf 2.59 installed. I can test the Ada build quickly though. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
[Bug c/39306] New: -fstack-check + large frame == SIGSEGV
Discovered as a failure of GDB test:
FAIL: gdb.base/stack-checking.exp: continue to breakpoint: breakpoint for big
frame
With current SVN head @144426:
/* t.c */
void foo() { char buf[524188]; }
int main() { foo(); return 0; }
i686-unknown-linux-gnu-gcc t.c -fstack-check ./a.out
Segmentation fault
AFAICT, this is a regression from 4.3.1
Problem also happens in x86_64-unknown-linux-gnu.
Minimal size to crash appears to be about 57058.
--
Summary: -fstack-check + large frame == SIGSEGV
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39306
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #20 from davids at webmaster dot com 2009-02-25 17:53 ---
I don't like this either:
tmp = var;
modified = false;
for (i = 0; i 100; i++)
{
if (i x)
tmp = i, modified = true;
}
if (modified)
var = tmp;
This can be a pessimization as well. If 'modified' is almost always false, the
'tmp = var;' can force a cache unshare for no reason. If this code is not
performance critical, the optimization is pointless. If it is, the
pessimization can be significant.
IMO, these kinds of optimizations are not worth doing. Almost any optimization
that can introduce an additional memory access risks a net performance loss in
some use cases. The compiler cannot determine the use case by static code
inspection.
Now, in this case, the 'tmp = var;' is obviously superfluous, you can just
eliminate it, so this isn't a good example of what I'm talking about. But in
general, an optimization should not *add* a memory operation the code did not
request unless you can show that it will always remove at least one operation
of comparable cost. Otherwise it can be a net performance loss all the time in
some use cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug middle-end/39306] -fstack-check + large frame == SIGSEGV
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-25 17:56 --- fstack-check is known to be broken on x86 GNU/Linux, see PR 13757. So I don't think this is a regression even. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39306
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #21 from matz at gcc dot gnu dot org 2009-02-25 18:04 --- The question if such transformation is or isn't worthwhile is independent from the issue at hand (which is about the validity in the light of the new memory model). If you find a clearly pessimizing but valid transformation create a bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-25 18:07 --- Really to me this is still a valid transformation even in the inside threads. If you want to be able to access via different threads, use locks, heavy or light weight ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug fortran/39304] ICE on module compilation
--- Comment #4 from kargl at gcc dot gnu dot org 2009-02-25 18:08 --- Created an attachment (id=17361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17361action=view) Reduced testcase -- kargl at gcc dot gnu dot org changed: What|Removed |Added Attachment #17358|0 |1 is obsolete|| Attachment #17359|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug fortran/39304] ICE on module compilation
-- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.5 4.3.3 4.4.0 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-02-25 18:10:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-02-25 18:19 --- Fixed with: Author: jamborm Date: Wed Feb 25 17:34:40 2009 New Revision: 144428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144428 Log: 2009-02-25 Martin Jambor mjam...@suse.cz * tree-inline.c (initialize_cfun): Remove asserts for calls_setjmp and alls_alloca function flags. (copy_bb): Set calls_setjmp and alls_alloca function flags if such calls are detected. Added: trunk/gcc/testsuite/g++.dg/torture/pr39259.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-25 18:24 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01185.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg01185.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-25 18:30 ---
Confirm. Also works with NAG f95. It fails with 4.1 to 4.4 and thus it does not
seem to be a regression.
It fails in spec_dimen_size for dimen=1, as-rank=1. Some more debugging
information from gfc_array_dimen_size:
- array-symtree-n.sym-name == fd (this is the function FD)
- array-symtree-n.sym-as == { rank = 1, type = AS_DEFERRED, ... }
- array-rank == 2
Thus the interesting thing is that the EXPR_FUNCTION is RANK 2 while the symbol
is only RANK 1.
A backtrace shows that it occurs for a MATMUL. The problem seems to be
constructs like:
ptr = MATMUL(FD(a, i), value(b))
where not
FUNCTION FD(x)
should be called but
FUNCTION FD_array_one(x, i)
as there is
INTERFACE FD
MODULE PROCEDURE FD, FD_one, FD_array_one, FD_matrix_one
END INTERFACE
#0 gfc_array_dimen_size (array=0x1329450, dimen=1, result=0x7fffd370) at
array.c:2036
#1 0x00412da8 in identical_dimen_shape (a=0x1329450, ai=1,
b=0x1329690, bi=2) at check.c:386
#2 0x004149f2 in gfc_check_matmul (matrix_a=0x1329450,
matrix_b=0x1329690) at check.c:1869
#3 0x0043371c in check_specific (specific=0x11857a0, expr=0x1329000,
error_flag=0) at intrinsic.c:3461
#4 0x00433a43 in gfc_intrinsic_func_interface (expr=0x1329000,
error_flag=0) at intrinsic.c:3667
#5 0x0046fb9d in resolve_function (expr=0x1329000) at resolve.c:1689
#6 0x0046bd2a in gfc_resolve_expr (e=0x1329000) at resolve.c:4754
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Keywords||ice-on-valid-code
Priority|P4 |P3
Summary|ICE on module compilation |ICE with MATMUL,
||specific/generic functions
||and rank checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-25 18:34:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #23 from davids at webmaster dot com 2009-02-25 18:35 ---
Really to me this is still a valid transformation even in the inside threads.
If you want to be able to access via different threads, use locks, heavy or
light weight ones.
Absolutely, you do use locks everywhere you write to a variable that might be
read from by another thread. The problem is that the compiler introduces locks
where you *don't* write to a variable.
It is simply impossible to use locks if the compiler can add a write where you
didn't expect one.
The classic example:
if(can_write) acquire_lock();
for(int i=0; i100; i++)
{
some_stuff(i);
if(can_write) shared_variable+=i;
}
if(can_write) release_lock();
Here this code does acquire a lock if it plans to modify the shared variable.
But the optimizations discussed will break this code.
Also, you can have the same problem with this kind of code without threads.
Imagine, for example, if the 'shared_variable' may be in read-only memory and
'can_write' indicates this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #24 from bonzini at gnu dot org 2009-02-25 18:43 --- Andrew, your comments #6 #8 #9 clearly show that you haven't understood the issue and are just talking past others. The other hand the transformation has been shown to be an optimization on single-thread cases; if it is bad for multiprocessors, it means it probably should be guarded by a flag (but what if the load is not necessary? should it use the same flag, a separate flag, or be always enabled?). But the IM code should be modified to use the flag as suggested by the C++ standard (and to avoid the load if it is not necessary, as it is in this case but not in the case explained by N2238). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug c/39307] New: avr-gcc ICE in start_function, at c-decl.c:6248
Seen in avr-gcc 4.3.3 built using the script that comes with FemtoOS 0.88.
[reg...@babel tmp40]$ avr-gcc -mmcu=atmega128 small.c
small.c:3: internal compiler error: in start_function, at c-decl.c:6248
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[reg...@babel tmp40]$ cat small.c
__attribute ((signal))
void __vector_15 (void)
{
}
[reg...@babel tmp40]$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.3/configure --prefix=/home/regehr/z/avr-gcc-test
--target=avr --with-gnu-ld --with-gnu-as --enable-languages=c,c++ --disable-nls
--disable-libssp --with-dwarf2
Thread model: single
gcc version 4.3.3 (GCC)
--
Summary: avr-gcc ICE in start_function, at c-decl.c:6248
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39307
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #7 from hjl at gcc dot gnu dot org 2009-02-25 18:49 --- Subject: Bug 39241 Author: hjl Date: Wed Feb 25 18:49:28 2009 New Revision: 144430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144430 Log: gcc/ 2008-02-25 H.J. Lu hongjiu...@intel.com PR rtl-optimization/39241 * jump.c (rtx_renumbered_equal_p): Remove 2 superfluous calls to subreg_offset_representable_p. gcc/testsuite/ 2008-02-25 H.J. Lu hongjiu...@intel.com PR rtl-optimization/39241 * gcc.dg/torture/pr39241.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr39241.c Modified: trunk/gcc/ChangeLog trunk/gcc/jump.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug c/39307] avr-gcc ICE in start_function, at c-decl.c:6248
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-25 18:50 --- *** This bug has been marked as a duplicate of 34299 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39307
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-02-25 18:50 --- *** Bug 39307 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||regehr at cs dot utah dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-25 18:55 --- Subject: Bug 39241 Author: hjl Date: Wed Feb 25 18:55:14 2009 New Revision: 144431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144431 Log: 2009-02-25 H.J. Lu hongjiu...@intel.com Backport from mainline: 2008-02-25 H.J. Lu hongjiu...@intel.com PR rtl-optimization/39241 * gcc.dg/torture/pr39241.c: New. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr39241.c - copied unchanged from r144430, trunk/gcc/testsuite/gcc.dg/torture/pr39241.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-25 18:55 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #10 from rakdver at gcc dot gnu dot org 2009-02-25 19:09 --- The difference between D.1254 = a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1) * 2; (original) and D.1255 = ((long unsigned int) a + 2) + (long unsigned int) ((unsigned int) len + 4294967295) * 2; (current) is mostly cosmetical; the test in the testcase should be made more robust, but other than that, there is no regression here. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2009- | |02/msg01185.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-25 19:18 --- (In reply to comment #10) The difference between D.1254 = a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1) * 2; (original) and D.1255 = ((long unsigned int) a + 2) + (long unsigned int) ((unsigned int) len + 4294967295) * 2; (current) is mostly cosmetical; the test in the testcase should be made more robust, but other than that, there is no regression here. The new loop is .L3: st2 [r14] = r33, 2 ;; cmp.ne p6, p7 = r15, r14 (p6) br.cond.sptk .L3 The old loop is mov ar.lc = r15 .L3: st2 [r14] = r33, 2 ;; br.cloop.sptk.few .L3 They are quite different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #8 from regehr at cs dot utah dot edu 2009-02-25 20:01 --- Sorry for the dup. This bug prevents compilation of almost all TinyOS apps using 4.3.3! Is there a workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work
--- Comment #12 from reichelt at gcc dot gnu dot org 2009-02-25 21:00
---
The culprit is in the function pushdecl_maybe_friend:
Functions declared extern C bypass the usual mechanism, because
duplicate_decls isn't called for them (see lines 727ff):
else if ((DECL_EXTERN_C_FUNCTION_P (x)
|| DECL_FUNCTION_TEMPLATE_P (x))
is_overloaded_fn (t))
/* Don't do anything just yet. */;
else if (t == wchar_decl_node)
[...snip...]
else
{
tree olddecl = duplicate_decls (x, t, is_friend);
Later only the binding for such functions is compared, which doesn't
take default parameters into account (see line 778ff):
if ((TREE_CODE (x) == FUNCTION_DECL)
DECL_EXTERN_C_P (x)
/* We should ignore declarations happening in system headers. */
!DECL_IN_SYSTEM_HEADER (x))
{
cxx_binding *function_binding =
lookup_extern_c_fun_binding_in_all_ns (x);
if (function_binding
!DECL_IN_SYSTEM_HEADER (function_binding-value))
{
tree previous = function_binding-value;
/* In case either x or previous is declared to throw an
exception,
make sure both exception specifications are equal. */
if (decls_match (x, previous))
[...snip...]
}
}
if (TREE_CODE (x) == FUNCTION_DECL || DECL_FUNCTION_TEMPLATE_P (x))
check_default_args (x);
I'm not sure how to proceed from here, so unassigning.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|REOPENED|NEW
Known to fail|3.4.6 4.0.3 4.1.0 4.1.1 |3.4.6 4.0.3 4.1.0 4.2.0
||4.3.0
Known to work|3.3.6 3.4.0 3.4.5 4.0.2 |3.3.6 3.4.0 3.4.5 4.0.0
|4.0.4 4.1.2 |4.0.1 4.0.2
Target Milestone|4.0.4 |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c/39308] New: ICE when compiling with -O[s123] -floop-interchange
In almost any nontrivial C project, using GCC 4.4 SVN (rev 144432) results in an ICE when building with any nonzero value of -O and -floop-interchange. -- Summary: ICE when compiling with -O[s123] -floop-interchange Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: il dot basso dot buffo at gmail dot com GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308
[Bug c/39308] ICE when compiling with -O[s123] -floop-interchange
--- Comment #1 from il dot basso dot buffo at gmail dot com 2009-02-25 21:49 --- Created an attachment (id=17362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17362action=view) Preprocessed C source (from bzip2 sources) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308
[Bug middle-end/36578] cast to long double not taken into account when result stored to a double
--- Comment #6 from janis at gcc dot gnu dot org 2009-02-25 22:09 --- Subject: Bug 36578 Author: janis Date: Wed Feb 25 22:08:55 2009 New Revision: 144436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144436 Log: 2009-02-25 Janis Johnson janis...@us.ibm.com gcc/ Backport from mainline: 2008-10-29 Joseph Myers jos...@codesourcery.com PR middle-end/36578 * convert.c (convert_to_real): Do not optimize conversions of binary arithmetic operations between binary and decimal floating-point types. Consider mode of target type in determining decimal type for arithmetic. Unless flag_unsafe_math_optimizations, do not optimize binary conversions where this may change rounding behavior. * real.c (real_can_shorten_arithmetic): New. * real.h (real_can_shorten_arithmetic): Declare. gcc/testsuite/ Backport from mainline: 2008-10-29 Joseph Myers jos...@codesourcery.com PR middle-end/36578 * gcc.dg/dfp/convert-bfp-13.c, gcc.dg/dfp/convert-bfp-14.c, gcc.dg/dfp/convert-dfp-fold-2.c, gcc.target/i386/pr36578-1.c, gcc.target/i386/pr36578-2.c: New tests. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-bfp-13.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-bfp-14.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-dfp-fold-2.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/pr39034.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36578-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36578-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/convert.c branches/gcc-4_3-branch/gcc/real.c branches/gcc-4_3-branch/gcc/real.h branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-25 22:35 --- Subject: Re: FAIL: gcc.dg/vect/vect-complex-1.c On Wed, 25 Feb 2009, irar at il dot ibm dot com wrote: Does adding attribute aligned, as below, help? Yes, it fixes the failure. Could you please attach slp-7.c's dump as well? I think it is a different problem there. Attached. Dave --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-25 22:35 --- Created an attachment (id=17363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17363action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39248
[Bug target/39296] ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2009-02-25 22:38 --- Subject: Re: ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large On Wed, Feb 25, 2009 at 01:47:45AM -, hjl dot tools at gmail dot com wrote: --- Comment #1 from hjl dot tools at gmail dot com 2009-02-25 01:47 --- I can't reproduce it on Linux with revision 144417. I believe it is a dup of PR 38988. Reopen it if it isn't fixed in trunk. *** This bug has been marked as a duplicate of 38988 *** Testing shows that the bug was fixed by revision 144417. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39296
[Bug c/39044] -Wformat warns on printf() with stringpointer as sole argument
--- Comment #3 from vapier at gentoo dot org 2009-02-25 23:58 --- i'd reconstruct this report as gcc not properly handling constant strings with printf() when the string is readily available to it and clearly does not change as for the kernel and this warning flag, that's a different issue -- vapier at gentoo dot org changed: What|Removed |Added CC||toolchain at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39044
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #9 from eric dot weddington at atmel dot com 2009-02-26 01:00 --- (In reply to comment #8) Sorry for the dup. This bug prevents compilation of almost all TinyOS apps using 4.3.3! Is there a workaround? See comment #4 of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug c++/29027] template conversion specialization found by using declaration
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-26 01:02 --- Subject: Bug 29027 Author: janis Date: Thu Feb 26 01:02:22 2009 New Revision: 13 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=13 Log: libcpp/ PR c/29027 * include/cpplib.h (CPP_N_DEFAULT): Define. * expr.c (interpret_float_suffix): Recognize d or D for double, return new value for default. (cpp_classify_number): Issue pedwarn for use of d or D in suffix. gcc/ PR c/29027 * c-lex.c (interpret_float): Default (no suffix) is double. gcc/testsuite/ PR c/29027 * gcc.dg/fltconst-1.c: Don't error for use of d or D in suffix. * gcc.dg/fltconst-2.c: New test. * gcc.dg/fltconst-double-pedantic-1.c: New test. * gcc.dg/fltconst-double-pedantic-2.c: New test. Added: branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-2.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-double-pedantic-1.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-double-pedantic-2.c Modified: branches/c-4_5-branch/gcc/ChangeLog.c45 branches/c-4_5-branch/gcc/c-lex.c branches/c-4_5-branch/gcc/testsuite/ChangeLog.c45 branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-1.c branches/c-4_5-branch/libcpp/ChangeLog.c45 branches/c-4_5-branch/libcpp/expr.c branches/c-4_5-branch/libcpp/include/cpplib.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29027
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #6 from ayers at fsfe dot org 2009-02-26 05:16 --- Created an attachment (id=17364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17364action=view) Updated patch (using and accessor function) inlcuding a test case For the record: This is an update of the existing patch which includes a test case. This was posted as an RFA: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01085.html with the following ChangeLog entries: 2009-02-23 Richard Frith-Macdonald r...@gnu.org PR libobjc/27466 * objc/objc-api.h: declare objc_set_unexpected function. * exception.c: implement objc_set_unexpected function. * libobjc.def: export objc_set_unexpected 2009-02-23 David Ayers ay...@fsfe.org PR libobjc/27466 * objc/execute/exceptions/handler-1.m. New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #7 from ayers at fsfe dot org 2009-02-26 05:24 --- Created an attachment (id=17365) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17365action=view) Alternative patch using a callback hook This patch was posted as an RFA: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01086.html With the following ChangeLog entry: 2009-02-23 Richard Frith-Macdonald r...@gnu.org David Ayers ay...@fsfe.org PR libobjc/27466 * objc/objc-api.h (_objc_unexpected_exception): Declare new hook. * exception.c (objc_exception_throw): Use hook. * libobjc.def (_objc_unexpected_exception): Export hook. 2009-02-23 David Ayers ay...@fsfe.org PR libobjc/27466 * objc/execute/exceptions/handler-1.m. New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884
--- Comment #6 from pault at gcc dot gnu dot org 2009-02-26 06:24 --- Subject: Bug 39292 Author: pault Date: Thu Feb 26 06:23:42 2009 New Revision: 14 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=14 Log: 2009-02-26 Paul Thomas pa...@gcc.gnu.org PR fortran/39292 * trans-array.c (gfc_conv_array_initializer): Convert all expressions rather than ICEing. 2009-02-26 Paul Thomas pa...@gcc.gnu.org PR fortran/39292 * gfortran.dg/initialization_22.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39292
[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm
--- Comment #6 from uros at gcc dot gnu dot org 2009-02-26 07:07 --- Subject: Bug 39058 Author: uros Date: Thu Feb 26 07:06:48 2009 New Revision: 15 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=15 Log: Backport from mainline: 2009-02-02 Jakub Jelinek ja...@redhat.com PR inline-asm/39058 * recog.h (asm_operand_ok): Add constraints argument. * recog.c (asm_operand_ok): Likewise. If it is set, for digits recurse on matching constraint. (check_asm_operands): Pass constraints as 3rd argument to asm_operand_ok. Don't look up matching constraint here. * stmt.c (expand_asm_operands): Pass NULL as 3rd argument to asm_operand_ok. testsuite/ChangeLog: Backport from mainline: 2009-02-02 Jakub Jelinek ja...@redhat.com PR inline-asm/39058 * gcc.target/i386/pr39058.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr39058.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/recog.c branches/gcc-4_3-branch/gcc/recog.h branches/gcc-4_3-branch/gcc/stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm
--- Comment #7 from ubizjak at gmail dot com 2009-02-26 07:23 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
