Re: Recent VCG changes break gfortran's -std=f95 option
Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. This noreturn attribute can be set to 1 by make_noreturn, but nothing ever sets it to 0, which is probably why we're experiencing this problem. I have to go and not enough time to check it in detail, but perhaps we should change that here: Index: intrinsic.c === --- intrinsic.c (revision 114340) +++ intrinsic.c (working copy) @@ -254,6 +254,7 @@ next_sym-resolve = resolve; next_sym-specific = 0; next_sym-generic = 0; + next_sym-attr.noreturn = 0; break; default:
Re: Recent VCG changes break gfortran's -std=f95 option
My first patch didn't even compile :( Here's a new one. Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. This noreturn attribute can be set to 1 by make_noreturn, but nothing ever sets it to 0, which is probably why we're experiencing this problem. I have to go and not enough time to check it in detail, but perhaps we should change that here: Index: intrinsic.c === --- intrinsic.c (revision 114340) +++ intrinsic.c (working copy) @@ -254,6 +254,7 @@ next_sym-resolve = resolve; next_sym-specific = 0; next_sym-generic = 0; + next_sym-noreturn = 0; break; default:
Re: GCC 4.2 Status Report (2006-06-04)
Joern RENNECKE wrote: In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote: As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, I think it's time to declare 4.2 feature-complete. I am still waiting for review of by auto-increment patches, and for Berndt to complete the cross-jump part struct-equiv patches, so that I can post an updated patch for the if-conversion part. At this point I think it's better to wait for 4.3. I like neither of the current proposed solutions - mine costs too much compile time, while yours is too much of a hack. A while back I did some CSiBE testing that did not show enough benefit for the loss of compile time. We need to figure out something better. Bernd
Re: Fw: GCC 4.2 Status Report (2006-06-04)
This status report has been a long time coming, for which I apologize. As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, That is unfortunate. Dorit did make a sincere effort to prepare her patches long ago (mid February) well before leaving, and Victor has been constantly pinging for reviews, ready to address them. Ayal. I think it's time to declare 4.2 feature-complete. That leaves us looking at regressions. There are lots; presently 56 P1s. About half of those are new in 4.2. So, we're not ready to create a 4.2 branch. Therefore, we need to make the mainline open for regression-fixes only to force ourselves to attack the open bugs. Please consider the mainline operating under release-branch rules as of 12:01 AM Wednesday, California time. That will give everyone a few days to check in any in-progress bug-fixes that are not regressions. At this time, I don't think it makes sense to set a 4.2 target branch date. We have to see how fast the bug-fixing goes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Wolfgang Mües [EMAIL PROTECTED] writes:
On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
(define_insn *arm_movqi_insn
[(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m)
(match_operand:QI 1 general_operand rI,K,m,r))]
I think you should go back to this (i.e. the unmodified version) and
only change the m into Q in the fourth alternative of operand 0.
See if that works, i.e. generates addresses that are valid for the
swp instruction.
No, that doesn't work:
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
__register_frame_info_table_bases':
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
satisfy its constraints: (insn 63 28 29 0
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:136 (set (mem/s/j:QI (plus:SI
(reg/v/f:SI 1 r1 [orig:102 ob ] [102]) (const_int 16 [0x10])) [0 S1
A32])
(reg:QI 12 ip)) 155 {*arm_movqi_insn} (nil)
(nil))
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
in reload_ cse_simplify_operands, at postreload.c:391
This is just a guess, but the insn above might be an output reload.
Reload instructions are not themselves reloaded. In other words,
if gcc needs to reload a QImode register out to a memory location,
it will assume that any m-r move is OK; it will not restrict the
reload to Q-r. This is by design. You can:
(1) Trap this in the movqi expander, if you can fix up the general
case without clobbering additional registers (unlikely).
(2) Define a reload_outqi pattern to handle general m-r moves.
You then get a scratch register to play with. (This interface
has changed (and improved) since I last used it.)
(3) Modify reload so that output memory operands are legitimised
differently (only if you're brave).
(4) Restrict QImode addresses to 'Q'.
It looks downthread like you've already decided to do (4). I just
wasn't sure from the thread whether you realised that output reloads
might be a specific problem. Sorry in advance if this was just noise. ;)
Richard
Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Ridge wrote: Ranjit Mathew wrote: Danny, I'm using the same configure flags that you have used for GCC 3.4.5 MinGW release (*except* for --prefix=/mingw, which is something like --prefix=/j/mingw/mgw for me), but the GCC I get is not relocatable at all, while I can put the MinGW GCC 3.4.5 release anywhere on the filesystem and it still works. :-( The GCC I get from my native MinGW build of the trunk is relocatable: Curiouser and curiouser! See the following output that shows what I was talking about (TEMP is set to C:\TEMP, so /tmp is mapped to C:\TEMP): - -- 8 -- C:\TEMP\mgwc:\temp\mgw\mymingw\bin\gcc -v hello.c Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw 32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr or Thread model: win32 gcc version 4.2.0 20060606 (experimental) c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -v - -iprefix c:\temp\mgw\mymingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c -quie t -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccuw.s ignoring nonexistent directory /tmp/mgw/mymingw/include ignoring nonexistent directory C:/TEMP/mgw/mymingw/i686-pc-mingw32/include ignoring nonexistent directory /mingw/include #include ... search starts here: #include ... search starts here: c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include C:/TEMP/mgw/mymingw/include C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/include End of search list. GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.2.0 20060606 (experimental). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918 Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279 c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mi ngw32/bin/as.exe -o C:\TEMP/ccOS.o C:\TEMP/ccuw.s c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/collect2.exe -Bdyn amic c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../crt2.o -L c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/mymingw/b in/../lib/gcc -LC:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/ mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib -LC :/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib -Lc:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../.. -LC:/TEMP/m gw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../.. C:\TEMP/ccOS.o -lmingw32 - lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmi ngw32 -lgcc -lmoldname -lmingwex -lmsvcrt C:\TEMP\mgwmove mymingw yourmingw 1 file(s) moved. C:\TEMP\mgwc:\temp\mgw\yourmingw\bin\gcc -v hello.c Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw 32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr or Thread model: win32 gcc version 4.2.0 20060606 (experimental) c:/temp/mgw/yourmingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet - v -iprefix c:\temp\mgw\yourmingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c - quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccktaa aa.s ignoring nonexistent directory C:/TEMP/mgw/mymingw/include ignoring nonexistent directory /tmp/mgw/mymingw/include ignoring nonexistent directory C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2. 0/include ignoring nonexistent directory C:/TEMP/mgw/mymingw/i686-pc-mingw32/include ignoring nonexistent directory /mingw/include #include ... search starts here: #include ... search starts here: c:/temp/mgw/yourmingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include End of search list. GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.2.0 20060606 (experimental). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918 Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279 hello.c:1:19: error: stdio.h: No such file or directory hello.c: In function 'main': hello.c:5: warning: incompatible implicit declaration of built-in function 'prin tf' C:\TEMP\mgw - -- 8 -- Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhU50Yb1hx2wRS48RAr1dAJ9fDgIvYe493D+uOCuCwC3HKRqBagCfXzRL DaA0CPYJBV3OfoPlSBK4jnc= =A+Jh -END PGP
Re: Fw: GCC 4.2 Status Report (2006-06-04)
On 6/6/06, Ayal Zaks [EMAIL PROTECTED] wrote: This status report has been a long time coming, for which I apologize. As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, That is unfortunate. Dorit did make a sincere effort to prepare her patches long ago (mid February) well before leaving, and Victor has been constantly pinging for reviews, ready to address them. rant Maybe you can look at some of the regressions of the vectorizer first, instead of adding new features without first addressing regressions? This could build up some trust that the newly added code will actually be maintained in the future. /rant For a quick bugzilla search, use the 4.2 regressions link on the gcc.gnu.org page and modify it to include -ftree-vectorize in the bug description. I count 3 P1 and 3 P2 regressions. Richard.
Re: ARM gcc 4.1 optimization bug.
Fengwei Yin wrote: Hi Daniel, I have already reported this bug. The bug number is #27363. I also tried the gcc snapshot 4.1.1-20060421. The bug is not fixed in this version too. On 5/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: I am using gcc4.1 for ARM to build Linux kernel. But there is a bug related to the gcc optimization. I assume this is correct mail list to report this bug. If not, please let me know. No, if you have a bug report, please use the bug reporting system. Please see: http://gcc.gnu.org/bugs.html Any news regarding this? Seems that I have the same problem. However, I first selected an other list http://sourceware.org/ml/crossgcc/2006-06/msg00032.html before finding this ;) Looking at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 it looks to me that this isn't fixed at 4.1.1? To create easier testcase, maybe it helps to compile only kernel's sound modules? I can reproduce this failure compiling sound modules of 2.6.17-rc5 with using different optimization levels for them: -Os - failure -O2 - failure -O0 - building of some modules fails -O1 - sound works! Best regards Dirk
Re: ARM gcc 4.1 optimization bug.
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote: Fengwei Yin wrote: Hi Daniel, I have already reported this bug. The bug number is #27363. I also tried the gcc snapshot 4.1.1-20060421. The bug is not fixed in this version too. On 5/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: I am using gcc4.1 for ARM to build Linux kernel. But there is a bug related to the gcc optimization. I assume this is correct mail list to report this bug. If not, please let me know. No, if you have a bug report, please use the bug reporting system. Please see: http://gcc.gnu.org/bugs.html Any news regarding this? Seems that I have the same problem. However, I first selected an other list http://sourceware.org/ml/crossgcc/2006-06/msg00032.html before finding this ;) Looking at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 it looks to me that this isn't fixed at 4.1.1? The bug is in state 'WAITING', which means there is not enough information for us to investigate the problem. See http://gcc.gnu.org/bugs.html for details of what we need. R.
Inline memcpy in GCC 4.1.1
Hi, I'm updating a port from 3.4.6 to 4.1.1. In 3.4.6, I hadn't implemented movmemsi patterns, but the compiler could still inline memcpy's (and also strcpys where source string is a const) by itself. After updating to 4.1.1, calls to memcpy are always generated. I've had a bash at implementing movmemsi, but in a test case that does a strcpy (dest, const), it appears the 4th parameter (alignment) is always 1, and doing a MEM_ALIGN on the source operand results in 8, despite the fact I have implemented the CONSTANT_ALIGNMENT and DATA_ALIGNMENT macros to ensure that STRING_CSTs and QImode ARRAY_TYPEs get implemented on a BITS_PER_WORD boundary (If I look at the assembler output, then that shows the string being aligned as expected on a word boundary). So, two questions: any idea why 4.1.1 is no longer able to automatically inline memcpys and why is the source operand for movmemsi not know to be as widely aligned as it actually is? Cheers, Jon
Build report for AIX 5.1
Hi, i just built GCC 4.1.1 on AIX 5.1 using the following commands: ../gcc-4.1.1/configure --with-libiconv-prefix=/usr --disable-nls --disable-multilib make bootstrap-lean make install $ config.guess powerpc-ibm-aix5.1.0.0 $ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.1.0.0 Configured with: /home/linke/temp/gcc-4.1.1/configure --with-libiconv-prefix=/usr --disable-nls --disable-multilib Thread model: aix gcc version 4.1.1 The system is an IBM pSeries M80 with AIX 5.1 at the latest patchlevel. The building c-complier is gcc 4.1.0 Make is gnu-make 3.80 The disable-xxx configure-options shouldn't be necessary, i used them for buildtime- and space-saving reasons. The whole build took less than two hours. Mario Linke
Re: Intermixing powerpc-eabi and powerpc-linux C code
You make a good point about the linker aspect but I was first most concerned about the code generation differences, if any. However, you are absolutely correct! A test is in order. I whipped up a quick test program and was able to successfully compile, link and run it, so it does indeed work! Thanks! On Thu, Jun 01, 2006 at 04:08:14PM -0700, Mike Stump wrote: This is a linker question, we don't do linkers here. In particular, the relocs have to be compatible, if you want to do reloc processing. You can use ld and resolve all the relocs and just slam in the bytes, but then, you're not using gcc to link per se. Why not just try it out and see?
Fw: GCC SC request about ecj
oops! forgot to cc the list. thanks Per. - Forwarded Message From: Per Bothner [EMAIL PROTECTED] To: Davanum Srinivas [EMAIL PROTECTED] Sent: Tuesday, June 6, 2006 11:49:23 AM Subject: Re: GCC SC request about ecj Davanum Srinivas wrote: Please see http://www.eclipsezone.com/eclipse/forums/t71850.html wget http://www.eclipse.org/jdt/core/patches/ecj_3.2RC3.jar;; should be enough. Did you mean to send this to the mailing list? If you want to be anonymous, I can post it for you. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Inline memcpy in GCC 4.1.1
In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote: So, two questions: any idea why 4.1.1 is no longer able to automatically inline memcpys and why is the source operand for movmemsi not know to be as widely aligned as it actually is? See PR middle-end/27226
Re: Recent VCG changes break gfortran's -std=f95 option
On Tue, Jun 06, 2006 at 08:16:54AM +0200, FX Coudert wrote: Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. This noreturn attribute can be set to 1 by make_noreturn, but nothing ever sets it to 0, which is probably why we're experiencing this problem. I have to go and not enough time to check it in detail, but perhaps we should change that here: Index: intrinsic.c === --- intrinsic.c (revision 114340) +++ intrinsic.c (working copy) @@ -254,6 +254,7 @@ next_sym-resolve = resolve; next_sym-specific = 0; next_sym-generic = 0; + next_sym-noreturn = 0; break; default: This patch is incorrect. The problem is that the make_noreturn() calls in add_subroutine are attached to the immediately preceding symbol name that is stuck in the list of intrinsics. In the case of -std=f95 and random_seed(), the three intervening routine are GFC_STD_GNU, so the make_noreturn() is applied to the wrong name. Andrew and FX thanks for pointing me in the right direction. If no one objects, I'll apply the enclosed patch later today. 2006-06-06 Steven G. Kargl [EMAIL PROTECTED] * intrinsic.c (add_subroutine): Make make_noreturn() conditional on the appropriate symbol name. -- Steve Index: intrinsic.c === --- intrinsic.c (revision 114435) +++ intrinsic.c (working copy) @@ -2232,7 +2232,8 @@ add_subroutines (void) add_sym_0s (abort, 1, GFC_STD_GNU, NULL); - make_noreturn(); + if ((gfc_option.allow_std GFC_STD_GNU) || gfc_option.flag_all_intrinsics) +make_noreturn(); add_sym_1s (cpu_time, 0, 1, BT_UNKNOWN, 0, GFC_STD_F95, gfc_check_cpu_time, NULL, gfc_resolve_cpu_time, @@ -2338,7 +2339,8 @@ add_subroutines (void) gfc_check_exit, NULL, gfc_resolve_exit, c, BT_INTEGER, di, OPTIONAL); - make_noreturn(); + if ((gfc_option.allow_std GFC_STD_GNU) || gfc_option.flag_all_intrinsics) +make_noreturn(); add_sym_3s (fgetc, 0, 1, BT_UNKNOWN, 0, GFC_STD_GNU, gfc_check_fgetputc_sub, NULL, gfc_resolve_fgetc_sub,
Re: [RFC] Optimization Diary
Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for dead code instead of just marking a text region and having a new _msg value meaning dead code? * DW_AT_GNU_OD_category The last value is 0x 0016. That seems wrong, I think it should end in 0010. What are action trails? Why is the action bit needed? The example in the text seems wrong, since there is an explicit _msg value for function is inlined, and multiple values for why a function might not be inlined. How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. * DW_AT_GNU_OD_msg I presume that GCC will somehow maintain the canonical values here. It seems important that there be a central process for registering these so that weird divergences don't crop up over time. Also perhaps a vendor extension range should be specified? In any case, the mechanisms here ought to be documented. A nit: * The first example is oddly formatted. The blue region encompasses an entire comment, but the salmon (? nice color choice :) region stops before the '*/'. And... surely the diary won't be marking text regions corresponding to comments anyway? I feel like I'm probably misunderstanding the point of this highlighting. Tom
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
Wolfgang Mües [EMAIL PROTECTED] writes:
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
__register_frame_info_table_bases':
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
satisfy its constraints:
[cut]
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
in reload_ cse_simplify_operands, at postreload.c:391
This is just a guess, but the insn above might be an output reload.
It is, in a peculiar (and not useful) way. Diffing the greg dump against
the lreg dump shows (using the example code I posted):
+(insn:HI 25 17 38 2 (set (reg:QI 3 r3)
+(reg:QI 3 r3 [110])) 158 {*arm_movqi_insn_swp} (nil)
+(nil))
-(insn:HI 25 17 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 101 [ x ])
+(insn 38 25 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 0 r0 [orig:101 x ]
+ [101])
(const_int 5 [0x5])) [0 variable.c2+0 S1 A8])
-(subreg:QI (reg:SI 110) 0)) 158 {*arm_movqi_insn_swp} (nil)
-(expr_list:REG_DEAD (reg:SI 110)
-(expr_list:REG_DEAD (reg/v/f:SI 101 [ x ])
-(nil
+(reg:QI 3 r3)) 158 {*arm_movqi_insn_swp} (nil)
+(nil))
I.e. change insn 25 to a nop and then add insn 38 as essentially a duplicate
of the original insn 25. I don't think reload was supposed to do that. The
documentation as well as comments in reload.c suggest that the address would
be loaded into a register. I'm running the code in a debugger to find out
why it doesn't happen.
Reload instructions are not themselves reloaded. In other words,
if gcc needs to reload a QImode register out to a memory location,
it will assume that any m-r move is OK; it will not restrict the
reload to Q-r. This is by design. You can:
(1) Trap this in the movqi expander, if you can fix up the general
case without clobbering additional registers (unlikely).
(2) Define a reload_outqi pattern to handle general m-r moves.
You then get a scratch register to play with. (This interface
has changed (and improved) since I last used it.)
This option stands a reasonable chance of being the end result. It just adds
more hair than I'd like to. It is one more thing that could go wrong, and so
on.
(3) Modify reload so that output memory operands are legitimised
differently (only if you're brave).
(4) Restrict QImode addresses to 'Q'.
It looks downthread like you've already decided to do (4).
Only as a temporary measure.
I just
wasn't sure from the thread whether you realised that output reloads
might be a specific problem.
I was not aware of this. It is only the second time I've seen postreload
complain about unsatisfied constraints. Thanks for pointing out this
problem.
--
Rask Ingemann Lambertsen
Re: [RFC] Optimization Diary
Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) I'll use separate email to answer this because it needs some explanation and it may spawn its own little email thread. * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for dead code instead of just marking a text region and having a new _msg value meaning dead code? In the case of dead code we could use _msg. However, _cmd is available to trigger some actions in tools that use this information. If we let our imaginations run wild then for example, lead developer towards __restrict documentation (i.e. launch lang. standard doc in one window and open particular page). Usually tools directly communicate_msg in plain English without performing any action. * DW_AT_GNU_OD_category The last value is 0x 0016. That seems wrong, I think it should end in 0010. Yes. What are action trails? For example, Loop A is unrolled. It is not a parameter manipulation hint, it is not a limitation and it is not a hint to developers. It is just a report of what optimizer did. This is default category. Why is the action bit needed? The example in the text seems wrong, since there is an explicit _msg value for function is inlined, and multiple values for why a function might not be inlined. It is used to provide distinctive feed back for action performed vs actions avoided. IDE may use different colors for actions performed vs actions avoided (blue vs salomn color :) How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. This should be encoded in msg text. It bit is used to distinguish build setting hint vs code change hint. Increase inline limit vs use __restrict. Parameter manipulation hints may be handled by build engineer in a big team, however you need code expert to justify use of __restrict. * DW_AT_GNU_OD_msg I presume that GCC will somehow maintain the canonical values here. It seems important that there be a central process for registering these so that weird divergences don't crop up over time. Also perhaps a vendor extension range should be specified? In any case, the mechanisms here ought to be documented. Yes. However, honestly, I do not know what is the best way to handle this. I am open for suggestion and I presume there is a established way to communicate such values, that are owned by GCC, to other tools. A nit: * The first example is oddly formatted. The blue region encompasses an entire comment, but the salmon (? nice color choice :) region stops before the '*/'. And... surely the diary won't be marking text regions corresponding to comments anyway? I feel like I'm probably misunderstanding the point of this highlighting. The second example is oddly formatted. Blue and salmon colored comments are generated by IDE based on diary entries. And IDE selected color based on action bit. - Devang
Re: [RFC] Optimization Diary
Tom Tromey wrote: * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. However, GCC provides hints along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. And text format is not suitable because of two reasons: 1) It is verbose. Try -opt_report in ICC. 2) This info is consumed by other tools (e.g. IDE, performance analyzer). It makes sense for a tool like Shark to use dwarf reader to get this info then parse raw text output. So, if 1) we need to keep this info on disk and available with final binary and 2) we use binary format to encode this info) then dwarf in object file is a natural selection. Command line developer can use extended dwarf reader to get the text messages. - Devang
Re: [RFC] Optimization Diary
These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. Thanks, Andrew Pinski
Re: [RFC] Optimization Diary
Andrew Pinski wrote: These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. That's what I meant when I said hints ... However, GCC provides (notes) along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. - Devang
Re: [RFC] Optimization Diary
Andrew Pinski wrote: These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. That's what I meant when I said hints ... However, GCC provides (notes) along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. If you are doing performance analysis the build log better be able to look at to make sure you are building with the correct options unless you trust the IDEs (which I and many other people don't). -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Tue, Jun 06, 2006 at 07:42:20AM +0200, Wolfgang Mües wrote: Rask, On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote: I think the comment in arm.h is wrong. The manual seems to agree with the code. Just to make it easy for beginners... In mainline GCC, it is defined like this in arm/constraints.md: (define_memory_constraint Q @internal In ARM state an address that is a single base register. (and (match_code mem) (match_test REG_P (XEXP (op, 0) Hmmm... I have searched 'Q' in the arm files. Not used in arm.md, only for some variants of arm (cirrus). Maybe only implemented for them? I assume there is no way to tell the direction in arm_legitimate_address_p() ? Hmmm. There isn't. arm_legitimate_address_p() just implements the macro GO_IF_LEGITIMATE_ADDRESS(MODE, X, LABEL). The only trick I know here is to use a different mode for special addresses. I'm writing an Intel 8086 backend which uses #define FUNCTION_MODE PQImode to let GO_IF_LEGITIMATE_ADDRESS handle function addresses specially. I just can't think of a way of using such a trick in this case. + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0 You should get a price for cleverness here! Thanks! Indeed it looks good until you think of volatile variables. +; Avoid reading the stored value back if we have a spare register. +(define_peephole2 + [(match_scratch:QI 2 r) [snip] As far as I can tell now, this works good. But I think there are many cases in which the source operand is not needed after the store. Is there a possibility to clobber the source operand and not using another register? I don't know if (match_scratch ...) might reuse the source operand. It can be attempted more specifically with an additional peephole definition: (define_peephole2 [(set (match_operand:QI 0 memory_operand ) (match_operand:QI 1 register_operand ))] TARGET_ARM TARGET_SWP_BYTE_WRITES peep2_reg_dead_p (1, operands[1]) [(parallel [(set (match_dup 0) (match_dup 1)) (clobber (match_dup 1))] )] ) Yet another register which stands a good chance of being reusable is the register containing the address. This can be covered as well (assuming the match_scratch version doesn't do this): (define_peephole2 [(set (mem:QI (match_operand 0 pmode_register_operand )) (match_operand:QI 1 register_operand ))] TARGET_ARM TARGET_SWP_BYTE_WRITES peep2_reg_dead_p (1, operands[0]) [(parallel [(set (mem:QI (match_dup 0)) (match_dup 1)) (clobber (match_dup 0))] )] ) I haven't tested these two peephole definitions. I can't think of any preferred order. It'll be your call, I guess. The register allocator chooses to use the lr register, in turn causing link register save alimination to fail, which doesn't help. I can't understand this without explanation... is it bad? GCC now needs more registers to hold addresses. The increased number of registers used disable som ARM specific optimizations of the function prologue and epilogue. This is bad, but only because the code becomes larger and slower. But I think that bytewritetest() suffers relatively much because it is a small function, using only a few registers to begin with. -- Rask Ingemann Lambertsen
Does Hegel Justify His Views?
I've studied a fair bit of analytic philosophy and feel that it is the rigorous arguments and detailed justification that separates worthwhile philosophy from mere speculation or faith based spiritual musings. Is there any reason for someone like me to take Hegel seriously? You've talked about the ideas he has but does he give us any good reason to believe they are true? Whenever I have tried to read Hegel I got the sense the arguments were incomplete and confused but I have to admit I haven't given him much of a chance. Does Hegel actually have good arguments for his views or is he just musing and throwing out ideas? If not why should we take him seriously? Peter (in Oakland)
Oops
Ignore that last email. It was sent to the wrong address. Peter Peter Gerdes -- [EMAIL PROTECTED] Find what I have to say interesting? Check out my blog or my analytic philosophy blog. On Jun 6, 2006, at 12:36 PM, Peter Michael Gerdes wrote: I've studied a fair bit of analytic philosophy and feel that it is the rigorous arguments and detailed justification that separates worthwhile philosophy from mere speculation or faith based spiritual musings. Is there any reason for someone like me to take Hegel seriously? You've talked about the ideas he has but does he give us any good reason to believe they are true? Whenever I have tried to read Hegel I got the sense the arguments were incomplete and confused but I have to admit I haven't given him much of a chance. Does Hegel actually have good arguments for his views or is he just musing and throwing out ideas? If not why should we take him seriously? Peter (in Oakland)
Re: Oops
On 6/6/06, Peter Michael Gerdes [EMAIL PROTECTED] wrote: Ignore that last email. It was sent to the wrong address. Thesis, antithesis, synthesis. -- David L Nicol fans of liza minelli should always be disconnected immediately -- Matthew Henry
Re: [RFC] Optimization Diary
Andrew Pinski wrote: Andrew Pinski wrote: These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. That's what I meant when I said hints ... However, GCC provides (notes) along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. If you are doing performance analysis the build log better be able to look at to make sure you are building with the correct options unless you trust the IDEs (which I and many other people don't). Two things. First this is not about IDE vs no IDE. Lets take one example. We, here at Apple, do not use IDE to build GCC. However we routinely install pre built compiler package on various machines and do compile time performance analysis using Shark. When Shark points me to a code hot spot, I want to know what optimizer was thinking about it. Second, optimization diary is not about what options are enabled and disabled. Compiler should not invoke any particular optimization pass just to add optimization diary entry. Its is a diary of optimization passes that are active. - Devang [ Interestingly, there is a long standing request, here at Apple, to list command line options in object file (even when optimization is not used). One of our intern tried to put them in STABS string. It may be a good idea to use DWARF in that case also. However it is orthogonal to optimization diary. It is a good small project, if someone is interested. ]
Re: Does Hegel Justify His Views?
On Tue, Jun 06, 2006 at 12:36:42PM -0700, Peter Michael Gerdes wrote: Does Hegel actually have good arguments for his views or is he just musing and throwing out ideas? If not why should we take him seriously? I don't think any of his patches have been accepted by GCC, so I'd say his arguments must not be very good. It's easy to see why: I downloaded _Pha:nomenologie des Geistes_ from Project Gutenberg and it won't even compile. There are in fact an astonishing number of the most basic syntax errors; it reads like something written by someone who didn't know C at all. Really atrocious coding, plus the comments are in German. Besides, we already have a Hegelian dialectic in GCC (C: thesis, C++: antithesis, Java: synthesis), so what do we need him for? Dustin pgpcNULfgid0J.pgp Description: PGP signature
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote: Devang Patel [EMAIL PROTECTED] writes: | [ Interestingly, there is a long standing request, here at Apple, to list | command line options in object file (even when optimization is not used). | One of our intern tried to put them in STABS string. It may be a good | idea to use DWARF in that case also. However it is orthogonal to | optimization diary. It is a good small project, if someone is | interested. ] I was under the impression that it was sort tkane care of by some patches from CodeSourcery. Though, it is possible I may have dreamted. Nope, it was Nick. -- Daniel Jacobowitz CodeSourcery
Re: [RFC] Optimization Diary
Is this what you want ? yes :) Thanks, - Devang
Re: [wwwdocs] Complete revamp of our web site
On Mon, Jun 05, 2006 at 09:53:00PM -0700, Andrew Pinski wrote: Also what about moving the News up to a noticeable spot since right now it is down in a corner so it looks out of place. In fact on my screen which is set to 1024x768, I have to scroll to get to the news. Yes, the top news needs to be on the front page, anything you have to scroll down for effectively isn't on the front page.
Re: [RFC] Optimization Diary
On Tue, 6 Jun 2006, Daniel Jacobowitz wrote: | On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote: | Devang Patel [EMAIL PROTECTED] writes: | | | [ Interestingly, there is a long standing request, here at Apple, to list | | command line options in object file (even when optimization is not used). | | One of our intern tried to put them in STABS string. It may be a good | | idea to use DWARF in that case also. However it is orthogonal to | | optimization diary. It is a good small project, if someone is | | interested. ] | | I was under the impression that it was sort tkane care of by some | patches from CodeSourcery. Though, it is possible I may have dreamted. | | Nope, it was Nick. Thanks for the correction. My apologies to Nick. -- Gaby
Re: [RFC] Optimization Diary
Devang == Devang Patel [EMAIL PROTECTED] writes: Tom * Why put the optimization diary into the object file? [...] Devang 2) This info is consumed by other tools (e.g. IDE, performance Devang analyzer). It makes sense for a tool like Shark to use dwarf Devang reader to get this info then parse raw text output. Thanks, this makes sense to me. I suggest adding this to your document as rationale. Tom
Re: [RFC] Optimization Diary
Devang == Devang Patel [EMAIL PROTECTED] writes: * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for dead code instead of just marking a text region and having a new _msg value meaning dead code? Devang In the case of dead code we could use _msg. However, _cmd is Devang available to trigger some actions in tools that use this Devang information. If we let our imaginations run wild then for Devang example, lead developer towards __restrict documentation Devang (i.e. launch lang. standard doc in one window and open Devang particular page). I agree, interconnections like the above are cool and useful. But this approach seems weird, because it is asking compiler maintainers to decide whether a given result is a message or an action. I think it would be more natural for the compiler to say what did or did not happen, and then to have the IDE, or whatever, apply interpretation to the record of the facts. I.e., no message/action distinction. What are action trails? Devang For example, Loop A is unrolled. It is not a parameter Devang manipulation hint, it is not a limitation and it is not a hint Devang to developers. It is just a report of what optimizer did. This Devang is default category. Ok. Why are these things stored in bits and not as a enumeration of possible values? Usually the use of bits implies that combinations of them are valid, but here it sounds as though the values are actually independent. How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. Devang This should be encoded in msg text. You mean it is implicit in the _msg value? If so, then the linkage between a given _msg value and a particular option ought to be documented. I realize this can't be done in a DWARF spec, but it at least needs to be done in GCC somewhere... it would be helpful to have this spelled out. Tom
Re: [RFC] Optimization Diary
Dan == Daniel Berlin [EMAIL PROTECTED] writes: Dan In addition to Tom's concerns, it seems to me to be a *really bad idea* Dan to try to come up with integer values for every single message, instead Dan of just placing a string there. One reason to prefer the numerical approach is that it makes localization of the user interface simpler. Dan The easiest way there is to just put a comment before the function or Dan whatever that generates the string saying it shouldn't be changed Dan between versions. We would also have to constrain the messages not to have any printf-style substitutions, since that would be an i18n disaster. Otherwise, yeah, I was wondering about this myself. Tom
Re: [RFC] Optimization Diary
Daniel Berlin [EMAIL PROTECTED] writes: Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file.
Re: [RFC] Optimization Diary
Geoffrey Keating wrote: Daniel Berlin [EMAIL PROTECTED] writes: Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO.
Re: [RFC] Optimization Diary
Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. In the same way numbering warning messages is a bad idea (yes ICC and a couple other compilers do but we should not). -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: Geoffrey Keating wrote: Daniel Berlin [EMAIL PROTECTED] writes: Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. I'm not concerned about what goes into the .o file, but what gets displayed on the screen. We cannot tell users to deal in one language. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. Alternatively, we could put *every* supported language into the .o file. But that bloats object files even more... smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
Geoffrey Keating wrote: On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: Geoffrey Keating wrote: Daniel Berlin [EMAIL PROTECTED] writes: Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. I'm not concerned about what goes into the .o file, but what gets displayed on the screen. We cannot tell users to deal in one language. You still need to be able to display the message for each number in all the languages you want, so it's going to be stored somewhere, you haven't solved the problem, just moved it completely to the consumer. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. Alternatively, we could put *every* supported language into the .o file. But that bloats object files even more... I have a very hard time believing that compiling and outputting messages in one language, and having someone who can't read those messages optimize and profile your application in another language, is a significant enough use case to be worried about. You can disagree. I'm just trying to tell you this has almost zero hope of ever being standardized if you keep it as a bunch of numbers. It also has almost zero hope of working over multiple compiler versions, being future proof in general, and not having other compiler vendors fight over message number namespace. --Dan
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:11 PM, Daniel Berlin wrote: Geoffrey Keating wrote: On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: Geoffrey Keating wrote: Daniel Berlin [EMAIL PROTECTED] writes: Tom Tromey wrote: Devang == Devang Patel [EMAIL PROTECTED] writes: Devang This version removes internal radar numbers and replaces s/ Devang DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. I'm not concerned about what goes into the .o file, but what gets displayed on the screen. We cannot tell users to deal in one language. You still need to be able to display the message for each number in all the languages you want, so it's going to be stored somewhere, you haven't solved the problem, just moved it completely to the consumer. Yes. However, you also get smaller .o files. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. Alternatively, we could put *every* supported language into the .o file. But that bloats object files even more... I have a very hard time believing that compiling and outputting messages in one language, and having someone who can't read those messages optimize and profile your application in another language, is a significant enough use case to be worried about. Right above, you said We control the debug output machinery generating this, and can simply tell it to only deal in one language. Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
Right above, you said We control the debug output machinery generating this, and can simply tell it to only deal in one language. Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: Right above, you said We control the debug output machinery generating this, and can simply tell it to only deal in one language. Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. What's the difference between that and just outputting a number and letting the IDE or other tool translate it? Either way, you're going to need a fixed set of strings or numbers to translate. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
--Apple-Mail-9--465959030 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: Right above, you said We control the debug output machinery generating this, and can simply tell it to only deal in one language. Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. What's the difference between that and just outputting a number and letting the IDE or other tool translate it? Either way, you're going to need a fixed set of strings or numbers to translate. Say I want to add a new one, I have to go through a committee with the number system while with a string I don't. -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote: On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: Right above, you said We control the debug output machinery generating this, and can simply tell it to only deal in one language. Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. What's the difference between that and just outputting a number and letting the IDE or other tool translate it? Either way, you're going to need a fixed set of strings or numbers to translate. Say I want to add a new one, I have to go through a committee with the number system while with a string I don't. I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. I don't understand why it has to be a standard string/message. Yes there could be some base set of messages. Also with the number system, you have to update the IDE when news ones get added while with the message way you don't unless you want to translate it to another language. -- Pinski
Re: which cctool on Darwin?
I believe I may have discovered the component that was causing the c++ regressions I was seeing on Darwin when fink was sourced. I have found that after I deinstalled bison v2.1 installed by fink, I was able to build gcc trunk on MacOS X 10.4 with fink sourced and still pass the c++ testsuite properly. I have built bison v2.3 and will see if that shows the same behavior as v2.1. Have there been any reports of problems with bison v2.1 and gcc trunk? Jack
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote: I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. In practice, using string identifiers does make conflicts less likely. It's also easier for a vendor to pick a unique prefix and be confident that Apple isn't going to assign some other meaning to csl-inline-bart. -- Daniel Jacobowitz CodeSourcery
Re: TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)
Hi, all, After I refer to the Intel paper titled Threading Methodology : Principles and Practices versin 2.0 published in 2003, I note the following message in the article mentioning:(from page 22, web site : http://cache-www.intel.com/cd/00/00/21/93/219349_threadingmethodology.pdf) _ OpenMP and thread libraries have mechanisms to create thread-local storage. Threads can safely access this storage without synchronization. Use the following declarations to create thread-local storage in different threading models: In OpenMP use threadprivate In Win32, use the TlsAlloc() function In Pthreads, use the pthread_key_create function __ From the above description, I think that gfortran with OpenMP compiler can also implemented the TLS using Win32 threads or Pthreads. Please comment on the above implementation methods. Thanks. Best regards, Henry Kar Ming Chan --- FX Coudert [EMAIL PROTECTED] wrote: [First, a warning: I'm neither an expert in TLS, nor in Windows nor in GCC guts can we have chance to solve the problem of threadprivate by adding the TLS support to mingw32? The support for TLS (Thread Local Storage) would probably come from the compiler itself. Windows has TLS (see for example http:// dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN documentation at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dllproc/base/tlsalloc.asp), so you'd only need to teach GCC how to call that. Now, I don't have competence, time and motivation to do that. So, if my analysis above is correct, there are three things you can do: ask around here if someone is interested in this and is planning to do it; do it yourself, if you have the competence; find someone you know, that you have leverage on, to do it :) Now, for an idea of how much work it represents... perhaps someone here can tell us? FX Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Rask, On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote: + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0 You should get a price for cleverness here! Thanks! Indeed it looks good until you think of volatile variables. Because volatile variables can change their values from another thread, and the readback will be false. Oh. gcc knows the volatile attribute here, I assume? As far as I can tell now, this works good. But I think there are many cases in which the source operand is not needed after the store. Is there a possibility to clobber the source operand and not using another register? I don't know if (match_scratch ...) might reuse the source operand. It can be attempted more specifically with an additional peephole definition: (define_peephole2 [(set (match_operand:QI 0 memory_operand ) (match_operand:QI 1 register_operand ))] TARGET_ARM TARGET_SWP_BYTE_WRITES peep2_reg_dead_p (1, operands[1]) [(parallel [(set (match_dup 0) (match_dup 1)) (clobber (match_dup 1))] )] ) I will try this. Yet another register which stands a good chance of being reusable is the register containing the address. Yes, but that is not allowed according to the specification of the swp instruction. The address register must be different from the other 2 registers. Is there any chance of gcc violating this constraint? regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
Re: [RFC] Optimization Diary
Andrew Pinski wrote: On Jun 6, 2006, at 9:49 PM, Devang Patel wrote: We can allocate space in numbering for vendor extensions. What happens when you compile two sources with two different compilers and they use the same number for vendor extension? What happens when another compiler uses 0x4104 TAG value for something else and GCC uses it for DW_TAG_GNU_BINCL ? You just end up with weird results in the IDE or performance analysis program. Also what happens after you fill up the vendor extension range? What happens when vendor extension range for TAGs and Attributes are full ? Also what happens when you change your compiler but not IDE, but you don't want to update the IDE? What happens when GCC adds new DWARF extension but you do not want to update GDB ? - Devang
Re: [RFC] Optimization Diary
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote: Andrew Pinski wrote: On Jun 6, 2006, at 9:49 PM, Devang Patel wrote: We can allocate space in numbering for vendor extensions. What happens when you compile two sources with two different compilers and they use the same number for vendor extension? What happens when another compiler uses 0x4104 TAG value for something else and GCC uses it for DW_TAG_GNU_BINCL ? Not my fault and not really related because we are creating a new standard and don't want to repeat this mistake, messages don't have this issue. You just end up with weird results in the IDE or performance analysis program. Also what happens after you fill up the vendor extension range? What happens when vendor extension range for TAGs and Attributes are full ? Who cares, we are trying making something which is useful and not making something which is going to be limited. Also what happens when you change your compiler but not IDE, but you don't want to update the IDE? What happens when GCC adds new DWARF extension but you do not want to update GDB ? Again, we are trying to make something useful and extendable. If you don't care about usefulness and extendibility then go ahead and use numbers. Having the message gets rid of having duplicated code in each program that processes the numbers, you have the message right away without doing extra work. You really should listen to Daniel Berlin if you ever want this to be officially part of the dwarf2 standard. Remember he is part of the committee there. You get extendibility for free and no need to change the IDE every thing you want to add a new diary entry. What more do you want something for free or something which limits the use? If you want something which is limited you may as well then just not use dwarf2 and instead write out a text file. -- Pinski
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-06 06:13 --- Subject: RE: ICE on complex assignment FX, Paul, I'm adding you to the CC list since this looks fully module-related. Oh Gee, thanks - that's all I need!.. I'll take a look at it this morning. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 06:15 --- (In reply to comment #7) Paul, I'm adding you to the CC list since this looks fully module-related. Oh Gee, thanks - that's all I need!.. Look at my C example, it is not related to Fortran at all. :). So you don't need to look into it :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06 06:18 --- Subject: RE: [4.1/4.2 Regression] ICE on complex assignment in nested function Andrew, Thanks, I just went at the mail in the wrong order. I discovered that it is not fortran by peaking at the PR. Who knows, maybe I can fix a C bug too? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #1 from csm at gnu dot org 2006-06-06 06:42 --- This is apparently caused by the default implementation of VMSecureRandom, which uses some threads concurrently modifying counters, and uses those counters to construct random bytes. It's odd that on GCJ this runs so slow; using the jamvm interpreter I didn't notice that much of a lag (on a fast machine, sure, but I wouldn't think that on any reasonably modern machine someone would get bothered enough to file a bug). -- csm at gnu dot org changed: What|Removed |Added CC||csm at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-06 06:42:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:47 ---
Noting the non-fortran tilt on this, it is interesting that
implicit COMPLEX (a-z)
CALL foo
CONTAINS
SUBROUTINE foo
t = s + s
END SUBROUTINE foo
END
is OK and produces declarations for s and t in foo. Alternatively, declaring s
and t in foo also works.
However,
COMPLEX s, t
CALL foo
CONTAINS
SUBROUTINE foo
t = s + s
END SUBROUTINE foo
END
puts the declarations in MAIN__, thusly:
foo ()
{
t = s + s;
MAIN__ ()
{
complex4 s;
complex4 t;
static void foo (void);
_gfortran_set_std (70, 127, 0);
foo ();
}
and triggers the ICE for any optimization level. In fortran parlance, it is
host or use association of the complex type that is broken.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug middle-end/27909] emacs M-x is undefined
--- Comment #2 from happyarch at gmail dot com 2006-06-06 07:13 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561 --- Comment #6 From Serge Belyshev 2006-03-08 12:46 --- This bug prevents emacs from working, it says M-x is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug middle-end/27909] emacs M-x is undefined
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 07:19 --- (In reply to comment #2) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561 That bug was fixed 3 months ago so that is not the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug java/27910] New: building fails due essentially to bad /bin/ksh on darwin
In order to build correctly in libjava and libjava/classpath, i had to:
1) in libjava/classpath/lib/Makefile.gcj, replace $(SHELL) by /bin/sh
2) in libjava/classpath/lib/gen-classlist.sh.in, replace the four occurrences
of while read pkg file with an appropriate awk sentence (eg for the first
one: awk '{ pkg=$1; file=$2; printf(%s %s %s/%s\n, pkg, dir, pkg, file); }'
[EMAIL PROTECTED]@ -)
3) in libjava/Makefile.in, replace cat tmp-ilist | while read f; do with for
f in `cat tmp-ilist`; do
It seems that the read built-in in darwin ksh does not read a line, but 4096
bytes.
--
Summary: building fails due essentially to bad /bin/ksh on darwin
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: powerpc-apple-darwin8.2.2
GCC host triplet: powerpc-apple-darwin8.2.2
GCC target triplet: powerpc-apple-darwin8.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 08:08 ---
Why are you trying to build with /bin/ksh? That is just wrong.
How is ${SHELL} is being set to /bin/ksh anyways, SHELL is set by MAKE to
/bin/sh by default unless someone else overrides it.
Did you set CONFIG_SHELL before building GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #2 from Denis dot Excoffier at airbus dot com 2006-06-06 08:33 --- Oops, i've found an unnoticed CONFIG_SHELL=/bin/ksh around the configure step in my build instructions. Sorry for that. Bug is not confirmed any longer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 08:37 --- Ok, closing as invalid, you might also want to report to Apple that ksh does not work correctly for POSIX cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-06-06 08:54
---
Based on David's descripion, a reduced testcase appears to be:
static short f[100];
int
bar (void)
{
return f[0];
}
void
foo (void)
{
int i;
for (i = 0; i 100; i++)
f[i]++;
}
Looking at the assembly output of -O2 -ftree-vectorize -maltivec
-mabi=altivec, it seems that f will only be guaranteed 2-byte
alignment with -fsection-anchors. Without -fno-section-anchors,
f gets the expected 16-byte alignment.
This is an ordering problem. gcc is compiling bar() first, and
generating code on the assumption that f has natural alignment.
The vectoriser then increases the alignment of f, which throws
off any layout based on the original natural alignment.
If bar() is compiled first, then gcc really does need to be able to
place f at a fixed offset in its section, so that it can use section
anchors to access f. So I think the possible fixes are:
(1) Don't use section anchors for f in bar()
(2) Don't increase the alignment of f in foo()
(3) Increase the alignment of f before compiling either foo() or bar()
(1) implies either (1a) not using section anchors for vectorisable variables
or (1b) disabling -fsection-anchors when -ftree-vectorize is in effect.
(2) implies either (2a) not increasing the alignment of variables that have
already been assigned a block offset or (2b) preventing -ftree-vectorize
from increasing alignment when -fsection-anchors is in effect.
(3) implies increasing the alignment of all vectorisable variables if
both -fsection-anchors and -ftree-vectorize are in effect.
Neither (2a) nor (2b) is acceptable IMO. (I don't think (2a) is
acceptable because the order of compilation is not guaranteed.)
(1) is a worst-case fall-back position, with (1a) obviously being
better than (1b). (3) seems more appealing, but only if we accept
that -fsection-anchors -ftree-vectorize may increase the alignment
of variables that do not in fact get vectorised. This is going to
be a data size hit. (Hopefully it will only be a small hit, and
I suppose -ftree-vectorize is already a speed over size
optimisation.)
If we choose (1) or (3), I suppose we should also add a gcc_assert()
that the vectoriser is not increasing the alignment of a variable
that has already been placed in a block (i.e. assert that (2a) would
then be a no-op).
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-06-06 09:02 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00284.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00284.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug libstdc++/27904] operator to floating point variable does not support inf, infinity, or nan
--- Comment #11 from pcarlini at suse dot de 2006-06-06 09:36 --- (In reply to comment #10) In C90 strtod does not say anything specifically about inf, etc. However, it does say: In other than the C locale, additional implementation-defined subject sequence forms may be accepted. In any case, to me this is a quality of implementation issue. A good implementation will accept inf, infinity and nan. Honestly, given also all the text in the C++03 standard I do not agree: currently we are not entitled to parse such strings, because they are not conforming to the grammar and to the text of Stage2. We must fail (as all the other implementations I'm aware of are doing). If you disagree, please file the issue as a DR, but... The fact that C99 explicitly accepts them seems sufficient justification to me. Sure, that is a very meaninful enhancement, which falls in the C99-compatibility area (already very active, see all the material coming from TR1) and should (will) be discussed in the context of the next standard (C++0x). More exactly, I reported already that the issue is known by Martin at least (I trust him about this section of the standard), but at this stage the policy is that reporting DRs for new features is not the best way to proceed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- 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|NEW |ASSIGNED Last reconfirmed|2006-02-24 10:46:37 |2006-06-06 09:59:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-06-06 10:10 --- This is now open since more than a year. Is there any hope of getting it fixed for gfortran 4.2? Correct uninitialized warnings are a very desirable feature IMO and have always been a stron point in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #13 from martin at mpa-garching dot mpg dot de 2006-06-06 10:11 --- (In reply to comment #12) Correct uninitialized warnings are a very desirable feature IMO Sorry, I meant unused of course :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug fortran/25923] [gfortran] garbled diagnostics with -O -Wuninitialized
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-06-06 10:14 --- Is it possible to fix this before gcc 4.2? Whenever I see these garbled warnings I have a very bad feeling that something completely unintended is happening inside the compiler, and I guess that many users could feel the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
[Bug fortran/24168] Problems with SPREAD and/or scalarization
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-06 10:26 --- Created an attachment (id=11607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11607action=view) Patch and testcase for the PR The problem lay in simplification of the binary expression because the rank of the operands was not transferred. I will submit tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24168
[Bug bootstrap/27901] ICE: On second stage boostrap with -O3
--- Comment #3 from paulg at chiark dot greenend dot org dot uk 2006-06-06 11:16 --- Tried the following 1) Bootstrap GCC 4.1.1 using a GCC 3.4.4 host compiler without STAGE1_CFLAGS or BOOT_CFLAGS set. 2) Bootstrap another clean copy of GCC 4.1.1 using the GCC 4.1.1 from step (1) as the host compiler using STAGE1_CFLAGS=-O3 -fomit-frame-pointer BOOT_CFLAGS=-O3 -fomit-frame-pointer. This fails in the same way which suggests that the bug causing this is still present in GCC 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27901
[Bug rtl-optimization/21676] [4.0/4.1/4.2 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #3 from gcc at pdoerfler dot com 2006-06-06 11:22 --- I get the following with -O3 -march=pentium4 -fomit-frame-pointer on a pentium4 gentoo machine: gcc-3.4.6 gcc-4.0.2 gcc-4.1.1 2.69s 4.14s 3.26s These are all with gentoo's patches. Also, current mainline is the same as gcc-4.1.1 I can confirm that the difference without -fomit-frame-pointer is much smaller. In fact, 3.4.6 and 4.1.1 are almost the same without it. -- gcc at pdoerfler dot com changed: What|Removed |Added CC||gcc at pdoerfler dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-06-06 11:46 --- (In reply to comment #3) This bug report is approaching its second anniversary. Does anybody still watch it or take care? Yes, Harald. I have been looking these last days at a number of array initializer problems. I have not entirely decided how to do this one yet: (i) Blasting through and expanding the array setion is one way; or (ii) Doing as Erik Edelmann suggested in another PR; use a normal assignment for the initialization and a static flag to make sure that it only is done once. The first is consistent with the existing structure and the second can be used to simplify a lot but will be much more work. This is why I am looking at initializer PRs as a package. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/27916] New: Problem with allocatable arrays inside OpenMP do loop
I've stumbled on a gfortran Fortran runtime error when using allocatable
arrays inside OpenMP PARALLEL DO LOOPS
Consider the folowing reduced testcase.
cat allocate_in_loop.f90
program allocate_in_loop
use omp_lib, only: omp_get_num_threads,omp_get_thread_num
implicit none
integer :: numthreads,n,it,i
integer, dimension(:), allocatable :: int_array
!
!$OMP PARALLEL DEFAULT(shared) NUM_THREADS(4)
numthreads=omp_get_num_threads()
!$OMP DO PRIVATE(n,it,int_array,i) SCHEDULE(static)
do n=1,numthreads
it=omp_get_thread_num()
allocate(int_array(3))
do i=1,3
int_array(i)=(it)*100+i
write(*,'(a,i2,a,i1,a,i4)') 'thread :',it,' --int_array(',
i,')=',int_array(i)
end do
deallocate(int_array)
end do
!$OMP END DO
!
!$OMP END PARALLEL
end program allocate_in_loop
According to what I read in the OpenMP 2.5 Specification - in sections 2.8.3.3
page 75 - the usage of the allocatable array is correct since I allocate it and
deallocate inside the OMP loop and it is not allocated upon entering the OMP DO
loop.
Gfortran compile fine with
gfortran -fopenmp allocate_in_loop.f90
But fails on execution with: Fortran runtime error: Attempting to allocate
already allocated array.
intel 9.1, pgi 6.1 and xl do fine, the output being for example...
./a.out
thread : 0 -- int_array(1)= 1
thread : 0 -- int_array(2)= 2
thread : 0 -- int_array(3)= 3
thread : 1 -- int_array(1)= 101
thread : 1 -- int_array(2)= 102
thread : 1 -- int_array(3)= 103
thread : 2 -- int_array(1)= 201
thread : 2 -- int_array(2)= 202
thread : 2 -- int_array(3)= 203
thread : 3 -- int_array(1)= 301
thread : 3 -- int_array(2)= 302
thread : 3 -- int_array(3)= 303
Good bug squashing
Benjamin
--
Summary: Problem with allocatable arrays inside OpenMP do loop
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benjamin dot reveille at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug fortran/27916] Problem with allocatable arrays inside OpenMP do loop
--- Comment #1 from benjamin dot reveille at gmail dot com 2006-06-06 12:01 --- For the fortran mailing list thread on this bug see: http://gcc.gnu.org/ml/fortran/2006-06/msg00096.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #14 from bonzini at gnu dot org 2006-06-06 12:10 --- Patch pr27390-more.patch was bootstrapped/regtested and the approach was confirmed to be ok by Roger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug fortran/27885] FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-06 12:14 --- Subject: Re: FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors) I wonder what outmode is in emit_library_call_value_1: tfom = lang_hooks.types.type_for_mode (outmode, 0); I might have a look to later during the weekend if I my move goes smooth. If I recall correctly, it is TImode, and NULL_TREE is returned. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27885
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #13 from guerby at gcc dot gnu dot org 2006-06-06 12:37 --- Subject: Bug 27769 Author: guerby Date: Tue Jun 6 12:37:01 2006 New Revision: 114429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114429 Log: 2006-06-06 Laurent GUERBY [EMAIL PROTECTED] PR ada/27769 mlib-utl.adb: Use Program_Name. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/mlib-utl.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #14 from guerby at gcc dot gnu dot org 2006-06-06 12:38 --- Subject: Bug 27769 Author: guerby Date: Tue Jun 6 12:37:36 2006 New Revision: 114430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114430 Log: 2006-06-06 Laurent GUERBY [EMAIL PROTECTED] PR ada/27769 mlib-utl.adb: Use Program_Name. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/mlib-utl.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #15 from laurent at guerby dot net 2006-06-06 12:43 --- Should be fixed now. -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug target/26051] [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-06 12:54 --- Subject: Re: [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86 steven at gcc dot gnu dot org writes: Rainer, there is no test case and no description for how to reproduce this. I couldn't find a smaller testcase, unfortunately. But is this still an issue at all? You seem to be able to report Solaris 10 test results, e.g. http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00113.html, for mainline. True: recent mainline bootstraps don't show this issue any longer. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26051
[Bug middle-end/27909] emacs M-x is undefined
--- Comment #4 from happyarch at gmail dot com 2006-06-06 13:02 --- Weird, it doesn't fixed. my gcc version is 4.2.0 20060603 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug bootstrap/27918] New: stage2 failed: broken linking / Relocations in generic ELF (EM: 62)
make boostrap (...) stage1/xgcc -Bstage1/ -B/local/devel/toolchain41/sparc-sun-solaris2.9/sparc-sun-solaris2.9/bin/ -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a: could not read symbols: File in wrong format note that `make all` works fine. -- Summary: stage2 failed: broken linking / Relocations in generic ELF (EM: 62) Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27918
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06 14:06 --- Created an attachment (id=11608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11608action=view) Patch for this and PR27583 This needs cleaning up and a testcase writing but it is nearly there. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #6 from fitzsim at redhat dot com 2006-06-06 14:07 --- On the JDK lib files are stored in $JAVA_HOME/jre/lib. I've recently moved some files, like libjawt.so, that would conflict for multiple, parallel libgcj installations to the same prefix, to $(libdir)/gcj-$(gcc_version). I think we should move all such files there, and that directory should be libgcj's equivalent to the JDK's $JAVA_HOME/jre/lib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug target/27918] stage2 failed: wrong compiler used for host genmodes.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 14:12 --- make boostrap This is invalid, you are trying to bootstrap a cross compiler which will never work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|bootstrap |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27918
[Bug c++/27722] [4.0 regression] ICE incrementing an array
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-06 14:21 --- Btw, the fix for PR27804 fixed the problem on mainline before Mark's patch went in. (This might be interesting for a backport to the 4.0 branch.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 14:26 --- What about instead of absolute numbers doing label subtraction for section anchors and then we can defer the decision for the layout of the section until after all functions are done compiling? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-06 14:26:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug testsuite/26614] make check fails during fixincludes testing.
--- Comment #2 from tomdkat at comcast dot net 2006-06-06 14:34 --- I do not get this problem with gcc 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26614
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 --- Created an attachment (id=11609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609action=view) assert to add if Jakub's idea is implemented. So do you want to fix it Jakub's way instead of hacking up the tree optimizer? or would you still prefer to simply apply my patch for now in 4.1 and 4.2? If/when Jakub's suggestion is implemented, I suggest adding the following assert so you will know you have actually fixed it. This assert will trigger whenever there is a duplicate DECL_UID on a variable. It triggers on testcases from both this PR and 26757. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #9 from richard at codesourcery dot com 2006-06-06 15:02
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
What about instead of absolute numbers doing label subtraction for
section anchors and then we can defer the decision for the layout of
the section until after all functions are done compiling?
I don't think symbolic offsets would work, if that's what you mean.
We need to know the constant offset so that (a) we can enforce
TARGET_{MIN,MAX}_ANCHOR_OFFSET (which is more important for other
targets than it is for PowerPC) and (b) we know for PowerPC-like
setups whether the offset needs an addis.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #10 from dje at gcc dot gnu dot org 2006-06-06 15:10 --- The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass. I do not understand why the alignment of the vectorized variables is not known at section anchor creation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #11 from richard at codesourcery dot com 2006-06-06 15:16 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec dje at gcc dot gnu dot org [EMAIL PROTECTED] writes: The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass. I do not understand why the alignment of the vectorized variables is not known at section anchor creation time. The rtl optimisations for bar() precede the tree optimisations for foo(). Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-06 15:18 --- (In reply to comment #10) The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass. I do not understand why the alignment of the vectorized variables is not known at section anchor creation time. Because we decided while processing with the first function that the alignment for the variable is set. And we do tree and rtl intermixed when processing functions so we look at f's alignment during processing bar and then we change it during foo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #13 from dje at gcc dot gnu dot org 2006-06-06 15:22 --- We're performing the auto-vectorization in unit-at-a-time-mode, so maybe we need to recompile the other functions. It seems that we're going to encounter more problems along these lines with LTO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug c++/26965] [4.0/4.1/4.2 Regression] Unnecessary debug info for unused consts in C++
--- Comment #8 from ian at airs dot com 2006-06-06 15:42 --- As I mentioned in the original submission, I'm pretty sure it is caused by RTH's patch for PR 23190. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #14 from richard at codesourcery dot com 2006-06-06 15:53 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec dje at gcc dot gnu dot org [EMAIL PROTECTED] writes: We're performing the auto-vectorization in unit-at-a-time-mode, so maybe we need to recompile the other functions. It seems that we're going to encounter more problems along these lines with LTO. Well, I'm not convinced recompilation is the way to go. I can't imagine it scaling well in pathological cases. If we're talking about long-term fixes, I think we should just make sure that we vectorise all functions before applying rtl optimisations to any of them. But that's all moot anyway: either approach will take a long time to implement. (Note that, as things stand, we've already written out the asm code for bar() by the time we vectorise foo().) As far as 4.2 fixes go, does anyone disagree with my earlier comment? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #7 from ayers at gcc dot gnu dot org 2006-06-06 16:05 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jun 6 16:05:47 2006
New Revision: 114435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114435
Log:
2006-06-06 David Ayers [EMAIL PROTECTED]
PR libobjc/13946
* Makefile.def: Add dependencies for libobjc which boehm-gc.
* Makefile.in: Regenerate.
* configure.in: Add --enable-objc-gc at toplevel and have it
enable boehm-gc for Objective-C.
Remove target-boehm-gc from libgcj.
Add target-boehm-gc to target_libraries.
Add target-boehm-gc to noconfigdirs where ${libgcj}
is specified.
Assert that boehm-gc is supported when requested for Objective-C.
Only build boehm-gc if needed either for Java or Objective-C.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/configure
trunk/configure.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-06 16:35 --- For other reasons it would be nice to be able to place sync points in the pass schedule where we re-start with going over all functions for the remaining passes. Per function SSA form is requires for this, though, and possibly more (like per function alias info). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
