Re: Official GCC git repository
Daniel Berlin wrote: I put my version of the gcc conversion (which has all branches but no tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update it appropriately. Note that i will not announce this anywhere until someone steps forward to actually maintain it because i do not know GIT. Neither of the people who volunteered have done it even after repeated prodding :( (I don't mean to shame them, i am simply pointing out that it appears we need new volunteers) Yes, unfortunately I don't seem to find much time to dedicate to this lately. Sorry, I'm overwhelmed by higher priority things at this time :-( -- \___/ |___|Bernie Innocenti - http://www.codewiz.org/ \___\ CTO OLPC Europe - http://www.laptop.org/
Re: US-CERT Vulnerability Note VU#162289
A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . But that's like putting the cart before the horses (and complaining that it does not work). You find a security problem, you find a solution, you find the compiler optimizes away, you blame the compiler. You don't look for an alternative, which would be the most sensible: compare the length with the size, without unnecessary pointer arithmetic. Since the length is unsigned, it's enough to do this: if (len (size_t) (max - ptr)) /* overflow */ ; Paolo
A question regarding define_split pattern
Hello all, I have the following define_insn and define_splt pattern (define_insn movhi_const [(set (match_operand:HI 0 register_operand =r,r,r,r,r) (match_operand:HI 1 immediate_operand L,K,N,O,i))] ) (define_split [(set (match_operand:HI 0 register_operand ) (match_operand:HI 1 immediate_operand ))] reload_completed ) In the define_insn for some alternatives i have '#' and for some i have the instruction template. But irrespective of whether '#' is present in the output template or not all the alternatives are being spilt. Should i be having a define_split specific for an alternative or only the '#' alternative will be split? Thanks for you time. Regards, Shafi
Re: IA-64 ICE on integer divide due to trap_if and cfgrtl
On Tue, Apr 15, 2008 at 6:27 AM, Ian Lance Taylor [EMAIL PROTECTED] wrote: Jim Wilson [EMAIL PROTECTED] writes: It seems odd that cfgrtl allows a conditional trap inside a basic block, but not an unconditional trap. The way things are now, it means we need to fix up the basic blocks after running combine or any other pass that might be able to simplify a conditional trap into an unconditional trap. I can work around this in the IA64 port. For instance I could use different patterns for conditional and unconditional traps so that one can't be converted to the other. Or I could try to hide the conditional trap inside some pattern that doesn't get expanded until after reload. None of these solutions seems quite right. But changing the basic block tree during/after combine doesn't seem quite right either. The other solution would be to fix cfgbuild to treat all trap instructions are control flow insns, instead of just the unconditional ones. I'm not sure why it was written this way though, so I don't know if this will cause other problems. I see that sibling and noreturn calls are handled the same way as trap instructions, implying that they are broken too. I think the current cfgbuild behaviour is just to avoid putting a barrier in the middle of a basic block. A conditional trap instruction is not necessarily a control flow instruction for the compiler--it's similar to a function call which may or may not return. An unconditional trap is similar to a function call which is known to not return. I guess the difference is that combine can't turn a function call which may or may not return into a function call which will not return. Since traps are uncommon, and since you can't do a lot of optimization around them anyhow, it's probably OK to make them always return true from control_flow_insn_p. At least it's worth trying to see if anything breaks. A similar issue exists on the tree level when you try to fix PR35468 the right way. Consider char *const line = /dev/ptyXX; line[8] = 1; ... the assignment to line[8] is a conditional trap which ccp transforms into /dev/ptyXX[8] = 1; which is invalid GIMPLE and we'd like to fold into a un-conditional trap (__builtin_trap(), as done elsewhere). Of course now you need to start splitting basic blocks in fold_stmt or teach its callers that it may need to cleanup themselves... both is kind of ugly, but of course we don't want every store to end a basic block either... Richard.
Re: Problem with reloading in a new backend...
Le lundi 14 avril 2008 à 18:27 -0700, Jim Wilson a écrit : On Tue, 2008-04-15 at 00:06 +0200, Stelian Pop wrote: - I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload kept generating incorrect insn (putting constants into EVEN_REGS for example). I'm not sure this is correct or if it hides something else... It does sound odd, but I can't really say it is wrong, as you have an odd set of requirements here. At least it is working which is good. Ok, thanks again. Stelian. -- Stelian Pop [EMAIL PROTECTED]
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin [EMAIL PROTECTED] wrote: To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? I am calling update_ssa (TODO_update_ssa), after all the statements are transferred. The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. Diego, the bsi iterators do not update the statements for you though it is not clear if this is a bug or not. The bsi iterators call update_modified_stmts, which says: /* Mark statement T as modified, and update it. */ static inline void update_modified_stmts (tree t) However, this only calls update_stmt_if_modified (IE it does not mark the statement as modified and update it, as it claims to). Sandeep, it should also suffice to call mark_stmt_modified *before* moving the statements (since the above routine should then update them). Thanks. I will use update_stmt, update_ssa now. You need to do more than that - you appearantly are moving uses of SSA names to a place where its definition is not available like if you do b_1 = 1; a_1 = b_1 + 1; and transform this to a_1 = b_1 + 1; b_1 = 1; which obviously cannot work. So updating SSA form won't help you and renaming the symbols will only make the verifier happy and leave you with wrong code. So you need to investigate what exactly you are doing wrong with your stmt movement. Richard.
template parameter does not hide class name
Hello all,
I have tested the following code on g++ 4.3, 4.2, 4.1 and 3.4.
#include iostream
struct B {
static const int x = 1;
};
struct A {
static const int x = 0;
template typename A
static void f() {
std::cerr A::x std::endl;
}
};
int main() {
A::fB();
return 0;
}
The program just write zero to the standard error, which means that the
template parameter does not hide the class name. I have tested other
compilers, and they write one to the standard error. I do not know surely,
but I mean this a bug in gcc or a very strange behaviour of c++ standard.
Best, Balazs
Re: RFC: named address space support
On Tue, 15 Apr 2008, Ben Elliston wrote: Hi Mark I'm not terribly familiar with this proposal. Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. According to: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822 .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This suggests that it's very close to being incorporated into the standard. Have I understood that correctly? No. All it means is that TR 18037 is being revised, not anything to do with the standard. This is a TR Type 2, not an IS, and remains a TR Type 2, not an IS. As I recall, for a long time WG14 had a revised version fixing problems in the original TR, but trouble getting ISO to accept it; all the status means is that ISO is now accepting the revised version for publication. (This revised version is N1275, I think; that should be used in place of N1169.) ISO has nothing to do with whether TRs may be incorporated in the standard in subsequent revisions. It may be involved if a standalone TR changes into a standalone IS, as was proposed for the draft TR 24747 (special mathematical functions), but I think that's the only TR related to ISO C with such a proposal. There is no C1x draft as yet (N1256, C99+TC1+TC2+TC3, is the base document for the revision). I don't think it's been decided which TRs might end up in the base C1x standard, though there's an Austin Group paper arguing that TR 19769 (u and U strings) should remain a TR and not be included in the standard. I don't know what might be being decided at the Delft meeting right now. The agenda has Status of TR 18037 as an unnumbered item. A TR Type 2 may be considered as indicating if you want a feature to do this, it may be a good idea to do it this way and so gain implementation experience for future standardization. As such, I think it is reasonable to continue to add features from such TRs to GCC, provided we understand that they are experimental and may be changed incompatibly in future to accord with future TR versions or changes in the course of inclusion in the IS; that unlike actual language standards, we will not try to provide options to support different versions of a TR in the same compiler version. (The same applies to informative annexes in an IS, which may have the same sort of content as a Type 2 TR, such as Annex G in C99.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: Moving statements from one BB to other BB.
Hi, To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. IIRC what he tries to do is loop fusion, and according to the error message that he gets, he probably needs to add the calculations of the induction variable(s) of the original loop to the new one, and replace their uses (or maybe just move phi nodes), Zdenek
bootstrap failure in gcc4.3.1 on hppa2.0w-hp-hpux11.00
revision 134311 mkdir -p -- hppa2.0w-hp-hpux11.00/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in hppa2.0w-hp-hpux11.00/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/bin/install -c checking for gawk... gawk checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for hppa2.0w-hp-hpux11.00-ar... /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ar checking for hppa2.0w-hp-hpux11.00-lipo... lipo checking for hppa2.0w-hp-hpux11.00-nm... /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/nm checking for hppa2.0w-hp-hpux11.00-ranlib... /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ranlib checking for hppa2.0w-hp-hpux11.00-strip... /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/strip checking whether ln -s works... yes checking for hppa2.0w-hp-hpux11.00-gcc... /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc -B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/ -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc -B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/ -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include accepts -g... yes checking for /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc -B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/ -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include option to accept ANSI C... none needed checking how to run the C preprocessor... /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc -B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ -B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/ -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include -isystem /appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include -E checking whether decimal floating point is supported... no checking whether fixed-point is supported... no checking for __attribute__((visibility(hidden)))... no checking whether the target asssembler upports thread-local storage... yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default commands Adding multilib support to Makefile in /raid/tecosim/it/devel/projects/develtools/src/gcc-4.3.1/libgcc multidirs= with_multisubdir= gmake[3]: Entering directory `/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/hppa2.0w-hp-hpux11.00/libgcc' # If this is the top-level multilib, build all the other gmake[3]: *** [all-multi] Error 1 gmake[3]: Leaving directory `/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/hppa2.0w-hp-hpux11.00/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1' gmake: *** [all] Error 2 Does anybody else has such issues? -- Mit freundlichen Grüßen / Best Regards Dipl.-Ing. Rainer Emrich Dept. Manager IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Ferdinand-Stuttmann-Straße 15 D-65428 Rüsselsheim Phone +49 (0) 6142 8272-330 Fax+49 (0) 6142 8272-249 Mobile +49 (0) 163 5694920 www.tecosim.com best partner for
Bootstrap failure on native mingw32
I'm not exactly sure how this one was introduced, but a bootstrap on native i686-pc-mingw32 dies in stage1 libgcc with: ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous prototype for 'getpagesize' ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types for 'VirtualProtect' c:/MinGW/include/winbase.h:1995: error: previous declaration of 'VirtualProtect' was here ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprotect' The prototype for VirtualProtect in libgcc2.c is: extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); In winbase.h, it is: BOOL __attribute__((__stdcall__)) VirtualProtect(PVOID,DWORD,DWORD,PDWORD); with: typedef unsigned long DWORD; typedef int WINBOOL; typedef WINBOOL BOOL; typedef DWORD *PDWORD; typedef void *PVOID; Does that ring a bell to anyone? Any idea why it's showing up now even though it looks like this code wasn't modified in the recent past (and my winbase.h hasn't changed since my last successful bootstrap, a month ago). Thanks, FX PS: My exact configure line is: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Bootstrap failure on native mingw32
[EMAIL PROTECTED] wrote on 15.04.2008 14:28:17: I'm not exactly sure how this one was introduced, but a bootstrap on native i686-pc-mingw32 dies in stage1 libgcc with: ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous prototype for 'getpagesize' ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types for 'VirtualProtect' c:/MinGW/include/winbase.h:1995: error: previous declaration of 'VirtualProtect' was here ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprotect' The prototype for VirtualProtect in libgcc2.c is: extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); In winbase.h, it is: BOOL __attribute__((__stdcall__)) VirtualProtect(PVOID,DWORD,DWORD,PDWORD); with: typedef unsigned long DWORD; typedef int WINBOOL; typedef WINBOOL BOOL; typedef DWORD *PDWORD; typedef void *PVOID; Does that ring a bell to anyone? Any idea why it's showing up now even though it looks like this code wasn't modified in the recent past (and my winbase.h hasn't changed since my last successful bootstrap, a month ago). Thanks, FX PS: My exact configure line is: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/ I remember that modification. This is related to a patch in config/i386/mingw32.h to include for libgcc2 the windows header. Danny said he tested this patch, but for this the libgcc2.c prototype is no longer necessary for mingw targets. Regards, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination.
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 08:37:36AM +0200, Bernie Innocenti wrote: Daniel Berlin wrote: I put my version of the gcc conversion (which has all branches but no tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update it appropriately. Note that i will not announce this anywhere until someone steps forward to actually maintain it because i do not know GIT. Neither of the people who volunteered have done it even after repeated prodding :( (I don't mean to shame them, i am simply pointing out that it appears we need new volunteers) Yes, unfortunately I don't seem to find much time to dedicate to this lately. Sorry, I'm overwhelmed by higher priority things at this time :-( Can anybody else can do it? -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature
Re: Official GCC git repository
Hi, Daniel Berlin [EMAIL PROTECTED] writes: I put my version of the gcc conversion (which has all branches but no tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update it appropriately. Note that i will not announce this anywhere until someone steps forward to actually maintain it because i do not know GIT. What else is needed exactly? The mirror is in place and gets automatically updated, so that's already enough for many people I think. Thanks, Ludovic.
Re: Official GCC git repository
Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: Daniel Berlin [EMAIL PROTECTED] writes: I put my version of the gcc conversion (which has all branches but no tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update it appropriately. Note that i will not announce this anywhere until someone steps forward to actually maintain it because i do not know GIT. What else is needed exactly? The mirror is in place and gets automatically updated, so that's already enough for many people I think. Actually I just cloned the repo and I can only see the following branches: $ git-branch -rl origin/HEAD origin/master origin/pre-globals-git Something's wrong with the import? Thanks, Ludovic.
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 01:20:29PM +1000, Hasjim Williams wrote: Suffice to say, it will compile, but when you try to run it, and your program tries to do the libcall to the sqrt function it will segfault, because there is no libcall sqrt defined. As far as I can tell, sqrt and div are the only major opcodes that are needed (for ieee754 glibc --with-fp) that aren't implemented in MaverickCrunch. I'm going to keep asking until I get something we can work with... you're reporting a bug in the compiler, so we need a test case and the exact error message. What is generating any kind of sqrt libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK does not exist. -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on native mingw32
I remember that modification. This is related to a patch in config/i386/mingw32.h to include for libgcc2 the windows header. OK. Bootstrap does proceed with the prototype removed, of course (it's not yet finished). Question is: can we remove it altogether, or are there still cases where it is needed? It currently is inside: #if defined(WINNT) ! defined(__CYGWIN__) ! defined (_UWIN) ... #ifdef __i386__ So, if it's WINNT and neither cywin nor uwin, are we guaranteed it's mingw? FX -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Bootstrap failure on native mingw32
FX [EMAIL PROTECTED] wrote on 15.04.2008 15:21:30: I remember that modification. This is related to a patch in config/i386/mingw32.h to include for libgcc2 the windows header. OK. Bootstrap does proceed with the prototype removed, of course (it's not yet finished). Question is: can we remove it altogether, or are there still cases where it is needed? It currently is inside: #if defined(WINNT) ! defined(__CYGWIN__) ! defined (_UWIN) ... #ifdef __i386__ So, if it's WINNT and neither cywin nor uwin, are we guaranteed it's mingw? I am uncertain about this. AFAICS this is just for mingw. Kai | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination.
Re: Bootstrap failure on native mingw32
[EMAIL PROTECTED] wrote on 15.04.2008 14:40:15: [EMAIL PROTECTED] wrote on 15.04.2008 14:28:17: I'm not exactly sure how this one was introduced, but a bootstrap on native i686-pc-mingw32 dies in stage1 libgcc with: ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous prototype for 'getpagesize' ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types for 'VirtualProtect' c:/MinGW/include/winbase.h:1995: error: previous declaration of 'VirtualProtect' was here ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprotect' The prototype for VirtualProtect in libgcc2.c is: extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); In winbase.h, it is: BOOL __attribute__((__stdcall__)) VirtualProtect(PVOID,DWORD,DWORD,PDWORD); with: typedef unsigned long DWORD; typedef int WINBOOL; typedef WINBOOL BOOL; typedef DWORD *PDWORD; typedef void *PVOID; Does that ring a bell to anyone? Any idea why it's showing up now even though it looks like this code wasn't modified in the recent past (and my winbase.h hasn't changed since my last successful bootstrap, a month ago). Here is a patch fixing this problem 2008-04-15 Kai Tietz [EMAIL PROTECTED] * libgcc2.c (L_trampoline): Disable VirtualProtect declaration if _WIN32 is defined. Cheers, Kai Index: gcc/gcc/libgcc2.c === --- gcc.orig/gcc/libgcc2.c +++ gcc/gcc/libgcc2.c @@ -2058,7 +2058,7 @@ getpagesize (void) #endif } -#ifdef __i386__ +#if defined(__i386__) !defined(_WIN32) extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); #endif =
Re: A question regarding define_split pattern
Mohamed Shafi [EMAIL PROTECTED] writes: I have the following define_insn and define_splt pattern (define_insn movhi_const [(set (match_operand:HI 0 register_operand =r,r,r,r,r) (match_operand:HI 1 immediate_operand L,K,N,O,i))] ) (define_split [(set (match_operand:HI 0 register_operand ) (match_operand:HI 1 immediate_operand ))] reload_completed ) In the define_insn for some alternatives i have '#' and for some i have the instruction template. But irrespective of whether '#' is present in the output template or not all the alternatives are being spilt. Should i be having a define_split specific for an alternative or only the '#' alternative will be split? Whether a define_split takes effect is independent of whether the output template is #. Setting the output template to # is just a shorthand way of saying give an error if this split does not occur. (There actually is one difference: if the output template is # gcc makes one last attempt to split the insn in the final phase. You could write your split predicate such that only that attempt will succeed. But it's hard to imagine a good reason to write it that way.) Ian
DU-chains Vs UD-chains
Hi all, i'm currently studing alias analysis, and i have some questions, for instance, when are the du/ud-chains calculated? Before translating to SSA form? If i'm not wrong the def-use chain connects a definition of a variable to all the uses it may flow to, and the use-def chain connects a use to all the definitions that may flow to it. But, what chain is better for data-flow analysis? Maybe the answer is both? Thanks in advance Fran
Warning during GCC bootstrap on i686-pc-mingw32
I've seen a weird warning during a bootstrap of mainline on native
i686-pc-mingw32, which I guess is related to the recent introduction
of MS printf formats. It can be reproduced on the following small
example:
$ cat foo.i
void format_gcov (void)
{
__builtin_printf (%I64d, (long long) 1);
}
$ ../prev-gcc/xgcc.exe -S foo.i -pedantic -Wall -Wno-long-long
foo.i: In function 'format_gcov':
foo.i:3: warning: ISO C does not support the '' ms_printf length modifier
I don't think it's the intended behaviour, as the error message is
rather unclear. Is it worth opening a PR?
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
[tuples] creating singleton sequences
Hey there.
Frequently we want to create a new sequence that contains one element.
This is especially common when wrapping things with a BIND or in a TRY
block.
I'm tired of typing the same thing over and over.
How about a convenience function like this?
Index: gimple.h
===
--- gimple.h(revision 134265)
+++ gimple.h(working copy)
@@ -189,6 +189,17 @@ gimple_seq_empty_p (const_gimple_seq s)
}
+/* Allocate a new sequence and initialize its first element with STMT.
*/
+
+static inline gimple_seq
+gimple_seq_alloc_with_stmt (gimple stmt)
+{
+ gimple_seq seq = NULL;
+ gimple_seq_add_stmt (seq, stmt);
+ return seq;
+}
Re: [tuples] creating singleton sequences
On 4/15/08 11:36 AM, Aldy Hernandez wrote: I'm tired of typing the same thing over and over. Lazy bum. How about a convenience function like this? Sure. Diego.
Where is restrict keyword used in dependence analysis?
Hello,
I am porting to GCC 4.3.0 for our VLIW processor, and try to utilize
improved restrict keyword support. Somehow, I find for normal data
types, including vector types up to 8bytes, the restrict keyword works
just fine. But for wider vector, such as 4 32-bit word type, the
restrict keyword doesn't work any more. For example, for the first two
following functions, compiler can unroll (-funroll-all-loops) loops and
produces good schedule, where load instructions of next iteration can be
moved beyond store instruction of this iteration. But for the third
example, it is different. As suggested in .sched2 file, the compiler can
only resolve dependence of next load instructions after store
instruction of this iteration is scheduled. I tried to print out
tree-ssa files by using -fdump-tree-all. Unliked previous GCC (4.2.1),
the information in those files is not helpful at all. I don't know
where to look at now. Could someone point me some files/functions/data
structures by which restrict keyword is used and passed to dependence
anaylsis part? Thanks in advance.
Bingfeng Mei
Broadcom UK
Example code:
typedef intV4W __attribute__ ((vector_size (16)));
typedef intV2W __attribute__ ((vector_size (8)));
void tst(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
void tst2(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
void tst3(V4W * restrict a, V4W * restrict b, V4W * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
Implementation of string-literal as template parameter
Hi, Recently i have posted an idea of new language feature to comp.lang.c++.moderated. That is String literal as template parameter? form 12.04.2008, if anyone is interested to see whole thread. The idea is to allow string-literals as template argument, and make them equivalent to variadic character pack 'char...'. For example: template char... Chars_ class Foo; Fooabc would be equivalent to Foo'a', 'b', 'c' I am interested in writing proof of concept implementation. Since i dont have expirience with g++ codebase, I wanted to ask: 1) Is it expected to be hard to implement? (which I rather dont expect to be, but better ask :-) 2) Any hints, how/where should I start? Thanks in advance for any feedback. Piotr Rak
Re: DU-chains Vs UD-chains
On Tue, Apr 15, 2008 at 10:59 AM, Fran Baena [EMAIL PROTECTED] wrote: Hi all, i'm currently studing alias analysis, and i have some questions, for instance, when are the du/ud-chains calculated? ud chains are implicit in SSA form, since each use only has one reaching definiiton. du chains are calculated after SSA by the operand scanner. Before translating to SSA form? Nope. If i'm not wrong the def-use chain connects a definition of a variable to all the uses it may flow to, and the use-def chain connects a use to all the definitions that may flow to it. But, what chain is better for data-flow analysis? one is useful for forward dataflow, the other is useful for backwards dataflow. Maybe the answer is both? Yes. Thanks in advance Fran
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 8:05 AM, Zdenek Dvorak [EMAIL PROTECTED] wrote: Hi, To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. Or at least that is my recollection
Re: Official GCC git repository
No, nothing is wrong wit he import, if you want all the remote branches, you have to ask git to get all the remote branches git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' Then fetch again. then, if you want to really see all the branches, including the remote ones, use git branch -a -l, not -r -l. HTH, Dan On Tue, Apr 15, 2008 at 9:14 AM, Ludovic Courtès [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: Daniel Berlin [EMAIL PROTECTED] writes: I put my version of the gcc conversion (which has all branches but no tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update it appropriately. Note that i will not announce this anywhere until someone steps forward to actually maintain it because i do not know GIT. What else is needed exactly? The mirror is in place and gets automatically updated, so that's already enough for many people I think. Actually I just cloned the repo and I can only see the following branches: $ git-branch -rl origin/HEAD origin/master origin/pre-globals-git Something's wrong with the import? Thanks, Ludovic.
Re: Where is restrict keyword used in dependence analysis?
On Tue, Apr 15, 2008 at 12:01 PM, Bingfeng Mei [EMAIL PROTECTED] wrote:
Hello,
I am porting to GCC 4.3.0 for our VLIW processor, and try to utilize
improved restrict keyword support. Somehow, I find for normal data
types, including vector types up to 8bytes, the restrict keyword works
just fine. But for wider vector, such as 4 32-bit word type, the
restrict keyword doesn't work any more. For example, for the first two
following functions, compiler can unroll (-funroll-all-loops) loops and
produces good schedule, where load instructions of next iteration can be
moved beyond store instruction of this iteration. But for the third
example, it is different. As suggested in .sched2 file, the compiler can
only resolve dependence of next load instructions after store
instruction of this iteration is scheduled. I tried to print out
tree-ssa files by using -fdump-tree-all. Unliked previous GCC (4.2.1),
the information in those files is not helpful at all.
How not?
If we don't know, we can't fix them :)
I don't know
where to look at now. Could someone point me some files/functions/data
structures by which restrict keyword is used and passed to dependence
anaylsis part? Thanks in advance.
You mean the dependence analysis used by the scheduler?
That stuff is in sched-deps.c
At the RTL level, restrict ends up being transformed into a different alias set.
At the tree level, restrict info is not used very much right now.
Example code:
typedef intV4W __attribute__ ((vector_size (16)));
typedef intV2W __attribute__ ((vector_size (8)));
void tst(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
void tst2(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
void tst3(V4W * restrict a, V4W * restrict b, V4W * restrict c)
{
int i;
for(i = 0; i 256; i++){
c[i] = a[i] + b[i];
}
}
Re: Official GCC git repository
Daniel Berlin [EMAIL PROTECTED] writes: No, nothing is wrong wit he import, if you want all the remote branches, you have to ask git to get all the remote branches git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' This will put the remote branch heads in refs/remotes, you might want to put them in refs/remotes/origin instead. $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' Then fetch again. then, if you want to really see all the branches, including the remote ones, use git branch -a -l, not -r -l. git branch -r should already show all remote branches (ie. every ref under refs/remotes), git branch -a shows you all local branches in addition. (And -l has no meaning unless you create a branch.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 1:12 PM, Andreas Schwab [EMAIL PROTECTED] wrote: Daniel Berlin [EMAIL PROTECTED] writes: No, nothing is wrong wit he import, if you want all the remote branches, you have to ask git to get all the remote branches git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' This will put the remote branch heads in refs/remotes, you might want to put them in refs/remotes/origin instead. $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' Then fetch again. then, if you want to really see all the branches, including the remote ones, use git branch -a -l, not -r -l. git branch -r should already show all remote branches (ie. every ref under refs/remotes), git branch -a shows you all local branches in addition. (And -l has no meaning unless you create a branch.) I hope this helps everyone understand why i have no desire to maintain the git setup :) Git is a foreign language to me, and one I am not particularly interested in becoming fluent in. I am happy to simply be able to ask the locals where the bathroom is.
Re: Moving statements from one BB to other BB.
Hi, To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Zdenek
-pthread switch and binary compatibitity
Hi there, Over at the Boost C++ libraries project we're trying to decide what is the correct thing to do when code is compiled with -pthread or not. The crux of the issue is this: if gcc/g++ is configured with the pthread threading model, then are object files always binary compatible irrespective of whether they are compiled with the -pthread command line option or not? If the answer is yes, then is it commonplace to link object files compiled with and without -pthread? Basically we're trying to decide whether to try and ensure that object files compiled with and without -pthread are always binary compatible, or whether to turn threading support on *only* when -pthread is specified (and _REENTRANT gets #defined). Many thanks for your help, John Maddock.
Re: Moving statements from one BB to other BB.
On 4/15/08 1:34 PM, Zdenek Dvorak wrote: Hi, To clarify what Richard means, your assertion that you have updated SSA information is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Right. Moving statements in SSA form needs to introduce name-name mappings (eg, as is done during loop unrolling). Diego.
Re: Official GCC git repository
Daniel == Daniel Berlin [EMAIL PROTECTED] writes: Daniel No, nothing is wrong wit he import, if you want all the remote Daniel branches, you have to ask git to get all the remote branches Daniel git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' Daniel, how did you setup the git repository? The branch heads are supposed to be located under /refs/heads/ on gcc.gnu.org, not under /refs/remotes/, where you generally find the remote references: those branches aren't supposed to be remote on the master repository. If you populate this repository by pushing from another one, the push command should use --mirror. Excerpt from the manual: --mirror Instead of naming each ref to push, specifies that all refs under $GIT_DIR/refs/heads/ and $GIT_DIR/refs/tags/ be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This way, branches will be kept under /refs/heads/, not put under /refs/remotes/. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: Official GCC git repository
Hi, Samuel Tardieu [EMAIL PROTECTED] writes: how did you setup the git repository? The branch heads are supposed to be located under /refs/heads/ on gcc.gnu.org, not under /refs/remotes/, where you generally find the remote references: those branches aren't supposed to be remote on the master repository. Indeed. I suppose you can still mv .git/remotes/* .git/heads/? Thanks, Ludovic.
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 2:23 PM, Samuel Tardieu [EMAIL PROTECTED] wrote: Daniel == Daniel Berlin [EMAIL PROTECTED] writes: Daniel No, nothing is wrong wit he import, if you want all the remote Daniel branches, you have to ask git to get all the remote branches Daniel git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' Daniel, how did you setup the git repository? Using git-svn. The branch heads are supposed to be located under /refs/heads/ on gcc.gnu.org, not under /refs/remotes/, For git-svn, it considers the svn branches to be remotes of the svn master. IE it acts as if the svn repository was a fake git repository, so the branches from svn are remote branches on the svn server. The local git master branch just happens to be an up-to-date non-modified branch of refs/remotes/trunk HTH, Dan
RE: Bootstrap failure on native mingw32
Committed as obvious.
This was already in my sources (for another reason) when I tested Kai's patch.
Sorry for not noticing.
Danny
* libgcc2.c [L_trampoline]: Remove unnecessary prototype for
Windows VirtualProtect function.
Index: libgcc2.c
===
--- libgcc2.c (revision 134329)
+++ libgcc2.c (working copy)
@@ -2058,10 +2058,6 @@
#endif
}
-#ifdef __i386__
-extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall));
-#endif
-
int
mprotect (char *addr, int len, int prot)
{
-Original Message-
From: FX [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 16 April 2008 12:28 a.m.
To: GCC Development; Danny Smith
Subject: Bootstrap failure on native mingw32
I'm not exactly sure how this one was introduced, but a bootstrap on
native i686-pc-mingw32 dies in stage1 libgcc with:
../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous
prototype for 'getpagesize'
../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types
for 'VirtualProtect'
c:/MinGW/include/winbase.h:1995: error: previous declaration of
'VirtualProtect' was here
../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous
prototype for 'mprotect'
The prototype for VirtualProtect in libgcc2.c is:
extern int VirtualProtect (char *, int, int, int *)
__attribute__((stdcall));
In winbase.h, it is:
BOOL __attribute__((__stdcall__))
VirtualProtect(PVOID,DWORD,DWORD,PDWORD);
with:
typedef unsigned long DWORD;
typedef int WINBOOL;
typedef WINBOOL BOOL;
typedef DWORD *PDWORD;
typedef void *PVOID;
Does that ring a bell to anyone? Any idea why it's showing up now even
though it looks like this code wasn't modified in the recent past (and
my winbase.h hasn't changed since my last successful bootstrap, a
month ago).
Thanks,
FX
PS: My exact configure line is: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/local
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --disable-nls
--build=i586-pc-mingw32 --enable-libgomp --disable-shared
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
gfortran+libcpp: linking objects from c-compiler
Hi all. To integrate libcpp into gfortran, I copy/adapt quite some code from the c frontend. For include-path handling, I found that I can nicely re-use the functions defined in c-incpath.c and exported by c-incpath.h. Now, linking gfortran, the linker of course complains about undefined references, namely app_path() and register_include_chains(). Is it acceptable to simply link in the C-frontend object to gfortran (as C is a required language and the .o file will be available)? Do I need to do something else in addition or instead, like renaming or moving functions, pushing them to a library or anything else? Comments are highly welcome! Regards Daniel
Re: Official GCC git repository
Andreas Schwab [EMAIL PROTECTED] writes: Daniel Berlin [EMAIL PROTECTED] writes: No, nothing is wrong wit he import, if you want all the remote branches, you have to ask git to get all the remote branches git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' This will put the remote branch heads in refs/remotes, you might want to put them in refs/remotes/origin instead. $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' Actually this is not such a good idea, as it confuses git remote (it considers all refs imported from refs/remotes/* as stale branches). The original command is also the one recommended by git-svn(1). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: -pthread switch and binary compatibitity
John Maddock [EMAIL PROTECTED] writes: The crux of the issue is this: if gcc/g++ is configured with the pthread threading model, then are object files always binary compatible irrespective of whether they are compiled with the -pthread command line option or not? Yes, modulo the #define of _REENTRANT. If the answer is yes, then is it commonplace to link object files compiled with and without -pthread? Yes. In general, all the -pthread option does is turn on -D_REENTRANT during compilation and -lpthread during linking. There is some cross-platform variation--different -D and -l options--but in no case does -pthread lead to a different ABI. Ian
Bootstrap failure on i686-apple-darwin9
At revision 134333, boostrap fails on i686-apple-darwin9 at stage 1 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4-work/gcc/explow.c -o explow.o ../../gcc-4.4-work/gcc/except.c: In function 'dw2_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3382: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3388: error: 'struct eh_status' has no member named 'call_site_data' ../../gcc-4.4-work/gcc/except.c: In function 'sjlj_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3398: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3404: error: 'struct eh_status' has no member named 'call_site_data' make[3]: *** [except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, 15 Apr 2008 09:15:45 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
I'm going to keep asking until I get something we can work
with... you're reporting a bug in the compiler, so we need a test case
and the exact error message. What is generating any kind of sqrt
libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK
does not exist.
gcc shouldn't call __aeabi_sqrt, since it doesn't exist. It could
however try to do a libcall through the optab to sqrtsf2, since
sqrt_optab does exist in optabs.h/c and genopinit.c ...
Ok, to try and test this out, I added this patch to gcc, and recompiled
gcc glibc --with-fp for crunch:
--- gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 17:59:35.0
+1000
+++ gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 18:02:08.0
+1000
@@ -3100,6 +3100,22 @@
TARGET_ARM TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP)
)
+(define_expand sqrtsf2_soft_insn
+ [(set (match_operand:SF 0 s_register_operand )
+ (sqrt:SF (match_operand:SF 1 s_register_operand )))]
+ TARGET_ARM !(TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP))
+ {
+ FAIL;
+ })
+
+(define_expand sqrtdf2_soft_insn
+ [(set (match_operand:DF 0 s_register_operand )
+ (sqrt:DF (match_operand:DF 1 s_register_operand )))]
+ TARGET_ARM !(TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP))
+ {
+ FAIL;
+ })
+
(define_insn_and_split one_cmpldi2
[(set (match_operand:DI 0 s_register_operand =r,r)
(not:DI (match_operand:DI 1 s_register_operand ?r,0)))]
I was expecting it to fail since now gcc shouldn't be able to expand
that operation. I double check glibc config.status, and with_fp=yes.
So, I'm not sure how glibc is doing it's sqrt routines on arm. In that
case I suspect that glibc doesn't call sqrt for VFP or FPA, then, and
you were right in your first e-mail.
glibc uses its own internal sqrt function, rather than the
sqrtsf2/sqrtdf2 opcode, even on FPA or VFP.
In any case if you want a test, then something like
gcc/testsuite/gcc.dg/arm-vfp1.c is enough (of course with different
dejagnu lines, e.g. dg-final scan-assembler lines) ...
I still think something like the above patch needs to be added to gcc,
just to ensure that the sqrtsf2 / sqrtdf2 libcall never happens, and an
error happens at compile time rather than runtime. In the future glibc,
uclibc or some standalone function could make use of the gcc sqrt,
rather than the glibc sqrt.
Anyway, I misunderstood how the toolchain gets assembled and I would
appreciate it someone could point out where the sqrt function is in
glibc, on arm.
Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ???
Re: Bootstrap failure on i686-apple-darwin9
Does this help? Thanks for tha answer, but now I have: ... ../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags': ../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member named 'epilogue_delay_list' make[3]: *** [except.o] Error 1 ... Dominique
Structured Exception Handling in gcc
Hi, I am looking for information on how GCC implements Structured Exception Handling (try/catch) in C++ programs. I would really appreciate any pointers that helped me understand the internals. Thank you, Rodrigo
Re: Structured Exception Handling in gcc
Rodrigo Dominguez [EMAIL PROTECTED] writes: I am looking for information on how GCC implements Structured Exception Handling (try/catch) in C++ programs. I would really appreciate any pointers that helped me understand the internals. gcc does not implement Structured Exception Handling in the Microsoft C++ sense. gcc does implement plain old C++ exception handling including try/catch. The ABI is documented here: http://www.codesourcery.com/cxx-abi/abi-eh.html Ignore the fact that this is labelled Itanium, it's used for all targets. Ian
Re: gfortran+libcpp: linking objects from c-compiler
Daniel == Daniel Franke [EMAIL PROTECTED] writes: Daniel Is it acceptable to simply link in the C-frontend object to Daniel gfortran (as C is a required language and the .o file will be Daniel available)? Do I need to do something else in addition or Daniel instead, like renaming or moving functions, pushing them to a Daniel library or anything else? I think the usual rule is that c-* files are either specific to the C front end, or in some cases, shared by the C family of front ends. Perhaps this particular file could just be renamed and added to libbackend.a. This isn't completely ideal, because c-incpath.c refers to cpp_reader and some front ends don't actually need libcpp ... but if I read the Makefile correctly it looks like all the front ends already link to libcpp, so maybe it isn't a big deal. Tom
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Wed, Apr 16, 2008 at 09:18:07AM +1000, Hasjim Williams wrote: glibc uses its own internal sqrt function, rather than the sqrtsf2/sqrtdf2 opcode, even on FPA or VFP. Always. That's how it is supposed to work; the expander allows GCC to optimize sqrt operations inline, for architectures where it is profitable to do so. But the backing function remains sqrt (sqrtf, sqrtl). The implementation of that lives in the C library and is not dependent on GCC for the body. Anyway, I misunderstood how the toolchain gets assembled and I would appreciate it someone could point out where the sqrt function is in glibc, on arm. Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ??? I don't know for sure, but it seems likely. Build glibc with debug info and step through it? -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on i686-apple-darwin9
Does this help?
Thanks for tha answer, but now I have:
...
../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags':
../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member
named 'epilogue_delay_list'
make[3]: *** [except.o] Error 1
...
Sorry, that hunk was left over of my other local changes I was testing.
Index: except.c
===
*** except.c(revision 134328)
--- except.c(working copy)
*** push_sleb128 (varray_type *data_area, in
*** 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = cfun-eh-call_site_data_used;
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i n; ++i)
{
! struct call_site_record *cs = cfun-eh-call_site_data[i];
size += size_of_uleb128 (cs-action);
}
--- 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl-eh.call_site_record);
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl-eh.call_site_record, i);
size += size_of_uleb128 (cs-action);
}
*** dw2_size_of_call_site_table (void)
*** 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = cfun-eh-call_site_data_used;
int size = 0;
int i;
for (i = 0; i n; ++i)
{
! struct call_site_record *cs = cfun-eh-call_site_data[i];
size += size_of_uleb128 (INTVAL (cs-landing_pad));
size += size_of_uleb128 (cs-action);
}
--- 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl-eh.call_site_record);
int size = 0;
int i;
for (i = 0; i n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl-eh.call_site_record, i);
size += size_of_uleb128 (INTVAL (cs-landing_pad));
size += size_of_uleb128 (cs-action);
}
[Bug libstdc++/35942] New: Self Reference In Dinamic Linked Library builds for building Cross-Compiler
While building a cross-compiler, the the libstdc++-v3 includes a copy of
Libtool script, which includes a reference to libstdc++ itself. This prevent
the user to build a new compiler without existing libstdc++ for the target
triplet.
The following is a patch that tested to be working for this problem, but I
think it should be done in a better way.
###BEGIN OF PATCH CODE##
diff -Naur gcc-4.3-20080410.orig/libstdc++-v3/src/Makefile.in
gcc-4.3-20080410/libstdc++-v3/src/Makefile.in
--- gcc-4.3-20080410.orig/libstdc++-v3/src/Makefile.in 2008-03-01
05:26:50.0 +1100
+++ gcc-4.3-20080410/libstdc++-v3/src/Makefile.in 2008-04-14
23:16:35.0 +1000
@@ -212,6 +212,7 @@
LIBS = @LIBS@
LIBSUPCXX_PICFLAGS = @LIBSUPCXX_PICFLAGS@
LIBTOOL = @LIBTOOL@
+LIBTOOLLINK = @[EMAIL PROTECTED]
LN_S = @LN_S@
LTLIBICONV = @LTLIBICONV@
LTLIBOBJS = @LTLIBOBJS@
@@ -472,7 +473,7 @@
# course is problematic at this point. So, we get the top-level
# directory to configure libstdc++-v3 to use gcc as the C++
# compilation driver.
-CXXLINK = $(LIBTOOL) --tag CXX --mode=link $(CXX) \
+CXXLINK = $(LIBTOOLLINK) --tag CXX --mode=link $(CXX) \
$(OPT_LDFLAGS) $(SECTION_LDFLAGS) $(AM_CXXFLAGS) $(LTLDFLAGS) -o $@
debugdir = debug
@@ -536,7 +537,8 @@
echo rm -f \$${dir}/so_locations\; \
rm -f $${dir}/so_locations; \
done
-libstdc++.la: $(libstdc___la_OBJECTS) $(libstdc___la_DEPENDENCIES)
+libstdc++.la: $(libstdc___la_OBJECTS) $(libstdc___la_DEPENDENCIES)
+ sed '/postdeps=/[EMAIL PROTECTED]@\-lm@' `echo $(LIBTOOL) | cut -d\
-f2`
`echo $(LIBTOOLLINK) | cut -d\ -f2`
$(CXXLINK) -rpath $(toolexeclibdir) $(libstdc___la_LDFLAGS)
$(libstdc___la_OBJECTS) $(libstdc___la_LIBADD) $(LIBS)
mostlyclean-compile:
###END OF PATCH CODE##
--
Summary: Self Reference In Dinamic Linked Library builds for
building Cross-Compiler
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: earthengine at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug c++/35909] [4.4 Regression] ICE with bit-field and const references
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-15 08:57 --- It did work with: GNU C++ (GCC) version 4.3.0 20080128 (experimental) [trunk revision 131899] (i386-apple-darwin8.10.1) But fails with: GNU C++ (GCC) version 4.4.0 20080304 (experimental) [trunk revision 132852] (i386-apple-darwin8.10.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #11 from rguenther at suse dot de 2008-04-15 08:58 --- Subject: Re: [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution On Tue, 15 Apr 2008, ghazi at gcc dot gnu dot org wrote: --- Comment #10 from ghazi at gcc dot gnu dot org 2008-04-15 01:36 --- (In reply to comment #8) I propose that we do the following: - add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is only well-defined for !isinf (x) !isinf (y). this doesn't result in a runtime penalty and informs people about the possible problem in their code (it is non-portable). IMHO the above warning would have limited coverage because there are other ways users can test the results of isinf that would run into the sign problem. Well, of course. A different workaround would be to canonicalize the return value of isinf to bool. Doesn't this change the interface defined by c99? Yes, we would need to hide that fact and always add promotion code to int via isinf() != 0. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
[Bug c/35746] [4.3/4.4 regression] ICE with undefined variables
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug c/35742] [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'goto_expr' not supported by pp_c_expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35742
[Bug bootstrap/35933] local variable used before set in fold-const.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-15 09:54 --- Doh. Rafael, this was you with http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00326.html -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, espindola at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35933
[Bug c/35744] [4.1/4.2/4.3 regression] ICE attributes for invalid types
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 09:33 --- IMHO this should be backported to gcc-4_3-branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug target/32424] [4.3/4.4 Regression] gcc.c-torture/compile/20050303-1.c FAILs
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
[Bug target/35455] [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-04-15 10:45 --- (In reply to comment #0) Front end and library are ready to handle this when implemented. Front-end is ready? Is ENCODING=UTF-8 related to UCS-4 support? Because if it is, then the front-end is not ready, it only supports a single character kind. (In reply to comment #1) This could be a bit tricky to get right. OTOH Fortran is fortunate enough that there are real strings and not char arrays like in C, so from a user perspective it should be pretty transparent. Well, I'm not too sure it's hard. We are not required to support UTF-8 strings as a character kind (that would be really hard) but just UCS-4 strings (ie UTF-32), which is basically (as I see it): - remove limitations in the front-end that there is only one character kind] - make a new character kind, as an array of 32-bit integers and a length - adjust library functions Then, I/O with UTF-8 encoding just needs UTF-8 -- UTF-32 conversions, which is only a few dozen lines of code (unless I'm confused). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug ada/16086] Legal program rejected, procedure of protected object should be visible
--- Comment #6 from sam at gcc dot gnu dot org 2008-04-15 11:03 --- Subject: Bug 16086 Author: sam Date: Tue Apr 15 11:02:58 2008 New Revision: 134312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134312 Log: 2008-04-15 Ed Schonberg [EMAIL PROTECTED] gcc/ada/ PR ada/16086 * sem_ch12.adb (Analyze_Formal_Subprogram): The default can be any protected operation that matches the signature, not only an entry, a regular subprogram or a literal. 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] gcc/testsuite/ PR ada/16086 * gnat.dg/prot_def.adb: New. Added: trunk/gcc/testsuite/gnat.dg/prot_def.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch12.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16086
[Bug ada/16086] Legal program rejected, procedure of protected object should be visible
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-15 11:04 --- Fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16086
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-15 11:20 --- This is a fortran FE bug. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-04-15 11:20:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #10 from sam at gcc dot gnu dot org 2008-04-15 12:00 --- Subject: Bug 28733 Author: sam Date: Tue Apr 15 11:59:39 2008 New Revision: 134313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134313 Log: 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] Gary Dismukes [EMAIL PROTECTED] gcc/ada/ PR ada/28733 * sem_ch8.adb (Analyze_Use_Package): Do not allow use of something which is not an entity (and hence not a package). (End_Use_Package): Ditto. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch8.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #11 from sam at gcc dot gnu dot org 2008-04-15 12:22 --- This has been fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types
--- Comment #6 from bonzini at gnu dot org 2008-04-15 12:26 --- The point of -fsplit-wide-types was to kill patterns like iorsi3 in AVR backend. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-15 12:34 --- Ok, let's leave that for a follow-up. Have you managed to test this? I could bootstrap/regtest on ppc-linu and ppc64-linux, but don't have time right now for further testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug ada/35880] GNAT does not generate debugging information on imported entities
--- Comment #9 from knoxj at att dot net 2008-04-15 13:31 --- I was going to update my bug report when I noticed Sam's comments. I used readelf -a -w test_pacs_cp_package.o to try to see what was happening, and I saw that the compiler was throwing out any information about the Ada definintion. I would have expected the compiler to hang onto the Ada debug information, but use the IMPORT information for code generation. The linker would then resolve the IMPORT name, and the debugger could see the Ada description. I too realized that shared memory was a red herring, and the real problem was simply the IMPORT implementation. Sam's sample illustrates this much better than the source files I submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug fortran/35943] New: -fbounds-check: actual character string shorter than dummy
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1a93179a80b6e6e8
The following program is invalid as the passed character string is too short
for the dummy argument. gfortran detects this at compile time (if contained)
and prints a warning; however, I expect that it also detects this at run time
with -fbounds-check.
This should be quite easy as substr has:
substr (strng, _strng)
i.e. the _strng size can be compared at run time.
(Note: Using character(len=n) the string length of the dummy might not be
known at compile time either.)
PROGRAM TST_STRING
CALL SUBSTR('HELLO THE WETHER IS NICE')
CALL SUBSTR('HELLO THE WETHER IS ')
CALL SUBSTR('HELLO THE WETHER ')
STOP
! CONTAINS
END
SUBROUTINE SUBSTR(STRNG)
CHARACTER(24) STRNG
WRITE(6,*) 'STRING=', STRNG
RETURN
END SUBROUTINE
! END PROGRAM
--
Summary: -fbounds-check: actual character string shorter than
dummy
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35943
[Bug fortran/35944] New: wrong result for MOD with kind=10 for some array argument values
The following program gives the wrong answers when the MOD arguments have kind = 10 and one is an array. It works when the kind is 4 or 8. program FA2083 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] implicit none integer j1,k parameter (k=10) !fails ! parameter (k=8) !works ! parameter (k=4) !works REAL(k) QDA1(10) REAL(k) QDA(10), qval print *, 'kind = ',k qda = (/ 1,2,3,4,5,6,7,8,9,10 /) QDA1 = MOD ( 1.1_k*( QDA(1) -5.0_k), P=( QDA -2.5_k)) DO J1 = 1,10 QVAL = MOD(1.1_k*(QDA(1)-5.0_k),P=(QDA(J1)-2.5_k)) print '(i3, 3f10.2)', j1, qda1(j1), qval, qval-qda1(j1) ENDDO END c:\gfortran:gfortran fa2083.f c:\gfortran:a kind = 10 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -0.40 -1.40 -1.00 5 -0.40 -1.90 -1.50 6 -0.40 -0.90 -0.50 7 -0.40 -4.40 -4.00 8 -0.40 -4.40 -4.00 9 -0.40 -4.40 -4.00 10 -0.40 -4.40 -4.00 c:\gfortran:gfortran fa2083.f c:\gfortran:a kind =8 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -1.40 -1.40 0.00 5 -1.90 -1.90 0.00 6 -0.90 -0.90 0.00 7 -4.40 -4.40 0.00 8 -4.40 -4.40 0.00 9 -4.40 -4.40 0.00 10 -4.40 -4.40 0.00 c:\gfortran:gfortran fa2083.f c:\gfortran:a kind =4 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -1.40 -1.40 0.00 5 -1.90 -1.90 0.00 6 -0.90 -0.90 0.00 7 -4.40 -4.40 0.00 8 -4.40 -4.40 0.00 9 -4.40 -4.40 0.00 10 -4.40 -4.40 0.00 -- Summary: wrong result for MOD with kind=10 for some array argument values Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-04-15 14:02 --- I agree with you for output: we currently do COMPATIBLE rounding and it shouldn't be too hard to change. The only case where we might not have control is for the last significant digit output by snprintf(), where we might rely somehow on the system library's implementation. For input, however, I think we don't really have control on what we do (we rely on the system strtod) and it is probably not that easy to change. I'll try to think about it some more. PS: for input, I have come to the conclusion that NEAREST and COMPATIBLE are really the same, as it is not possible for a decimal value to be exactly halfway between two machine-representable floating point values. Can someone confirm/infirm this? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #16 from bergner at gcc dot gnu dot org 2008-04-15 14:36 --- I'll fire off a bootstrap and regtest of Alan's patch on powerpc64-linux and running the test suite in 32-bit and 64-bit modes (ie, -m32 and -m64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-15 15:10 --- Subject: Bug 35751 Author: jakub Date: Tue Apr 15 15:09:42 2008 New Revision: 134317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134317 Log: PR c/35751 * c-decl.c (finish_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * decl.c (layout_var_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * gcc.dg/gomp/pr35751.c: New test. * g++.dg/gomp/pr35751.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr35751.C trunk/gcc/testsuite/gcc.dg/gomp/pr35751.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug fortran/35945] New: Complex module-based overloading fails
If a type is renamed on import and then an unrenamed copy is also imported, and
overloaded functions are called then gfortran fails to compile with a blocked
by an incompatible object error. The code compiles cleanly with {NAG, ifort,
g95}.
Not sure if this is a bug or non-standard code, though I suspect the former.
Thanks,
Joanthan Hogg
Full test case:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ make
gfortran-4.3 -c stype.f90
gfortran-4.3 -c dtype.f90
gfortran-4.3 -c test.f90
test.f90:15.29:
subroutine fred(sval, dval)
1
test.f90:16.15:
use stype
2
Error: The type 'overloaded_type' cannot be host associated at (1) because it
is blocked by an incompatible object of the same name declared at (2)
make: *** [test.o] Error 1
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat test.f90
program test
use stype, overloaded_type_s = overloaded_type
use dtype, overloaded_type_d = overloaded_type
implicit none
type(overloaded_type_s) :: sval
type(overloaded_type_d) :: dval
sval%part = 1
dval%part = 2
call fred(sval, dval)
contains
subroutine fred(sval, dval)
use stype
type(overloaded_type_s), intent(in) :: sval
type(overloaded_type_d), intent(in) :: dval
call overloaded_sub(sval)
call overloaded_sub(dval)
end subroutine
end program
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat stype.f90
module stype
implicit none
type overloaded_type
real :: part
end type
interface overloaded_sub
module procedure overloaded_sub_s
end interface
contains
subroutine overloaded_sub_s(otype)
type(overloaded_type), intent(in) :: otype
print *, s type = , otype%part
end subroutine
end module
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat dtype.f90
module dtype
implicit none
type overloaded_type
double precision :: part
end type
interface overloaded_sub
module procedure overloaded_sub_d
end interface
contains
subroutine overloaded_sub_d(otype)
type(overloaded_type), intent(in) :: otype
print *, d type = , otype%part
end subroutine
end module
--
Summary: Complex module-based overloading fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
GCC build triplet: x86_64-unknown-linux-gnu
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=35945
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-15 15:19 --- Subject: Bug 35751 Author: jakub Date: Tue Apr 15 15:18:41 2008 New Revision: 134318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134318 Log: PR c/35751 * c-decl.c (finish_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * decl.c (layout_var_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * gcc.dg/gomp/pr35751.c: New test. * g++.dg/gomp/pr35751.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35751.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35751.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-decl.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 15:21 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug fortran/35946] New: wrong result with array constructor as argument to ATAN2
The following program gives the wrong answers when an array constructor with a complicated implied do is used as an argument to REAL which is then used as an argument to ATAN2. Dick Hendrickson program try_fa6013 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] call fa6013(10,1,-1) end program subroutine FA6013 (nf10,nf1,mf1) integer, parameter :: kv=4!fails ! integer, parameter :: kv=8!fails REAL(KV) DDA1(10) REAL(KV) DDA2(10) REAL(KV) DDA(10), dval dda = (/ 1,2,3,4,5,6,7,8,9,10/) print '(10f5.1)', REAL((/(J1,J1=nf10,nf1,mf1)/),KV) !works DDA1 = ATAN2 ( (/(REAL(J1,KV),J1=1,10)/) , $ REAL((/(J1,J1=nf10,nf1,mf1)/),KV)) !fails !$ REAL((/(J1,J1= 10, 1, -1)/),KV)) !works DDA2 = ATAN2 ( DDA, DDA(10:1:-1) ) DVAL = .09967_kv !atan2(1.0,10.0) print '(i3,3f10.5)', 1, dda1(1),dval, dval-dda1(1) DO J1 = 2,10 DVAL = DDA2(J1) print '(i3,3f10.5)', j1, dda1(j1),dval, dval-dda1(j1) 100 ENDDO END c:\gfortran:gfortran fa6013.f c:\gfortran:a 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.11066 0.09967 -0.01099 2 0.24498 0.21867 -0.02631 3 0.40489 0.35877 -0.04612 4 0.58800 0.51915 -0.06886 5 0.78540 0.69474 -0.09066 6 0.98279 0.87606 -0.10674 7 1.16590 1.05165 -0.11425 8 1.32582 1.21203 -0.11379 9 1.46014 1.35213 -0.10801 10 0.0 1.47113 1.47113 -- Summary: wrong result with array constructor as argument to ATAN2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug middle-end/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-04-15 15:37 --- Subject: Re: [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others Sorry for the problems. Can you give this patch a try? I'd wrongly assumed that one of the subregs would always be paradoxical. The patch fixes this PR and PR ada/35687. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug fortran/35947] New: wrong answers with array constructor argument to IEOR
The following program gives wrong answers when an array is used in an array constructor as an argument to IEOR. Dick Hendrickson program try_fa6077 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] call fa6077 ( 10, 1, -1, (/1,2,3,4,5,6,7,8,9,10/)) end subroutine FA6077 (nf10,nf1,mf1, ida) INTEGER IDA1(10) INTEGER IDA2(10), ida(10) IDA1 = IEOR((/1,2,3,4,5,6,7,8,9,10/), $(/(IDA(J1),J1=10,1,-1)/) ) IDA2 = IEOR ((/1,2,3,4,5,6,7,8,9,10/), (/10,9,8,7,6,5,4,3,2,1/) ) print '(10i3)', (/1,2,3,4,5,6,7,8,9,10/), $(/10,9,8,7,6,5,4,3,2,1/),ida1,ida2 END SUBROUTINE c:\gfortran:gfortran fa6077.f c:\gfortran:a 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 8 10 4 2 0 2 4 10 8 10 11 11 11 3 3 3 3 11 11 11 -- Summary: wrong answers with array constructor argument to IEOR Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35947
[Bug c/35948] New: -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
The following source, without the (void*) overrides, will throw an warning
(as expected), when compiled with -Wall:
$ gcc -o memcpy-fortify -Wall memcpy-fortify.c
memcpy-fortify.c: In function 'main':
memcpy-fortify.c:21: warning: passing argument 1 of 'memcpy' discards
qualifiers from pointer target type
memcpy-fortify.c:22: warning: passing argument 1 of 'strcpy' discards
qualifiers from pointer target type
With (void*) it is (as expected) silent. With -O2, it is silent, but with
-D_FORTIFY_SOURCE != 0, the qualifier override is ignored:
$ gcc -o memcpy-fortify -Wall -O2 -D_FORTIFY_SOURCE=2 memcpy-fortify.c
memcpy-fortify.c: In function 'main':
memcpy-fortify.c:21: warning: passing argument 1 of 'memcpy' discards
qualifiers from pointer target type
memcpy-fortify.c:22: warning: passing argument 1 of 'strcpy' discards
qualifiers from pointer target type
This will cause problems for builds that run with -Werror.
/*
* gcc -o memcpy-fortify -Wall -Werror -O2 -D_FORTIFY_SOURCE=2 memcpy-fortify.c
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include stdint.h
#include string.h
#include stdint.h
#include inttypes.h
int main(int argc, char * argv[])
{
char *foo = strdup(string one);
char *bar = strdup(string two);
const char *baz = (const char *)foo;
printf(%s\n, foo);
memcpy((void*)baz, bar, strlen(bar)+1);
strcpy((void*)baz, bar);
printf(%s\n, foo);
return 0;
}
--
Summary: -D_FORTIFY_SOURCE discards qualifier overrides on
{str,mem}cpy
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kees at outflux dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug c/35948] -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-15 16:35 --- This is not a GCC bug but rather a glibc issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 16:42 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-12 03:35:42 |2008-04-15 16:42:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35948] -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
--- Comment #2 from kees at outflux dot net 2008-04-15 16:44 --- Erk, right. Sorry for the noise. -- kees at outflux dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug translation/35177] Error in the french traduction
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-04-15 17:42 --- Thanks Jim for letting us (TP) know. I'll take care of it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-15 17:42:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35177
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-15 18:46 --- Bug fixed in AdaCore tree, will eventually be committed to FSF tree. -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|sam at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-30 20:52:57 |2008-04-15 18:58:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #8 from sam at gcc dot gnu dot org 2008-04-15 19:06 --- Subject: Bug 22387 Author: sam Date: Tue Apr 15 19:05:29 2008 New Revision: 134326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134326 Log: 2008-04-15 Ed Schonberg [EMAIL PROTECTED] gcc/ada/ PR ada/22387 * exp_ch5.adb (Expand_Assign_Record): Within an initialization procedure for a derived type retrieve the discriminant values from the parent using the corresponding discriminant. 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] gcc/testsuite/ PR ada/22387 * gnat.dg/specs/corr_discr.ads: New. Added: trunk/gcc/testsuite/gnat.dg/specs/corr_discr.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/exp_ch5.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #9 from sam at gcc dot gnu dot org 2008-04-15 19:06 --- This has been fixed in GCC SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug c++/35949] New: 'const' attribute applied to typedefed type in methods's return is ignored
In the following code 'const VR' in declaration of the return value of 'kk'
works as just 'VR', without constness.
In arguments 'const VR' is applied as const.
code example
typedef int X;
struct S {
typedef X VR; // --- VR is declared as X by-reference
X x;
// uncomment one of these two lines:
const VR kk(VR) const { return (x); } // --- bug: first 'const' is
ignored and function is defined as returning *not* const causing compiler error
message
// const X kk(VR) const { return (x); } // --- ok: function is defined as
returning const by-reference
};
void f() {
typedef S::VR VR;
const X (S::*fn)(VR) const; // ---: ask for the function returning
by-reference
fn = S::kk; // --- error message here
}
--
Summary: 'const' attribute applied to typedefed type in methods's
return is ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
--- Comment #4 from burnus at gcc dot gnu dot org 2008-04-15 19:08 --- I agree with you for output: we currently do COMPATIBLE rounding I wanted to write this when I approved the code, but I found one *printf function and checking the POSIX standard one finds: f, F The double argument shall be converted to decimal notation [...] The low-order digit shall be rounded in an implementation-defined manner. Therefore, I think COMPATIBLE is a good guess, but I'm not sure whether COMPATIBLE is always true. (In reply to comment #3) I agree with you for output: we currently do COMPATIBLE rounding and it shouldn't be too hard to change. The only case where we might not have control is for the last significant digit output by snprintf(), where we might rely somehow on the system library's implementation. Well, I would argue that this digit is the most important for rounding ... Does this mean we have to roll out our own implementation which replaces snprintf? For input, however, I think we don't really have control on what we do (we rely on the system strtod) and it is probably not that easy to change. I probably miss something, but where on input do you need to round? PS: for input, I have come to the conclusion that NEAREST and COMPATIBLE are really the same, as it is not possible for a decimal value to be exactly halfway between two machine-representable floating point values. Can someone confirm/infirm this? I wanted to mention BOZ I/O, but there you don't have a decimal point. But still I'm not sure that you cannot dream up a decimal number which has one digit too much for the machine-representible FP number. But in any case NEAREST is contained in COMPATIBLE as NEAREST does not describe what to to if the numbers are equidistant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug c++/35949] 'const' attribute applied to typedefed type in methods's return is ignored
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-15 19:10 --- const VR is different from const X. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug c++/35261] GCC4.3 internal compiler error: verify_flow_info failed
--- Comment #2 from truedfx at gentoo dot org 2008-04-15 19:17 --- Created an attachment (id=15479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15479action=view) bug.ii I ran into this same error with different code, which I posted to http://gcc.gnu.org/ml/gcc-help/2008-04/msg00190.html but reduced further to the attached. It, like the original code, fails with GCC 4.3.0, GCC 4.3-20080410, and GCC-4.4-20080411, when GCC is configured with --enable-checking. gcc -c -O is enough to show it with this: $ ~/gcc/bin/gcc -c -O bug.ii bug.ii: In function void h(): bug.ii:7: error: BB 13 can not throw but has EH edges bug.ii:7: 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/bin/gcc --version gcc (GCC) 4.4.0 20080411 (experimental) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35261
