Example of debugging GCC with toplevel bootstrap
Hello, this is a real log of debugging GCC (with stage1 C miscompiling stage2 Fortran), including finding the miscompilation and fixing it. I hope it helps understanding the way toplevel bootstrap works. ../configure I just need two stages because I know that stage1 C miscompiles stage2 Fortran. I use all-stage2, rather than bootstrap2, to avoid building target libraries. This is like doing "make -C gcc bootstrap2" in the old scheme. make all-stage2 STAGE1_LANGUAGES=c,fortran I use the stage1 compiler to make the target libraries, to avoid that the miscompilation hits in libgfortran. make stage1-start make all-target-libgfortran Unfortunately, all target directories are staged, even non-bootstrapped ones, because of multilibbing. So I copy everything in the stage1 target directory to the stage2 target directory. But this annoyance is actually good because in the future it will allow me to use the same libgcc for both executables. This shields from potential miscompilations of the stage2 C front-end (we have a buggy stage1 compiler!). make stage # This is just for simplicity cp -R stage1-powerpc*/* stage2-powerpc*/ Run stage2's regression tests (in this case I could have found the failing testcase from the PR, but I was disconnected from Internet): make stage2-start ; make -C gcc check-fortran As soon as a test fails, make sure it did not fail in stage1. make stage1-start ; make -C gcc check-fortran RUNTESTFLAGS=dg.exp=complex_intrinsic_1.f90 Find out the command line to f951 (in reality, I cut & pasted from the dejagnu log file and just added -### to the end). gcc/gfortran -Bgcc ../gcc//testsuite/gfortran.dg/complex_intrinsic_1.f90 -S -### Ok, we are ready to debug. In this case, I prefer to have two distinct debuggers, and having directories names stage1-gcc and stage2-gcc actually helps me. Hence the first make invocation. make stage cp ../gcc/testsuite/gfortran.dg/complex_intrinsic_1.f90 aaa.f90 stage1-gcc/f951 aaa.f90 -fPIC -o stage1.s stage2-gcc/f951 aaa.f90 -fPIC -o stage2.s diff stage1.s stage2.s This was just to be sure that I identified a failure mode. After reducing the testcase a bit, I set to find the front-end miscompilation. gdb --args stage1-gcc/f951 aaa.f90 -o stage1.s gdb --args stage2-gcc/f951 aaa.f90 -o stage2.s ... some time later a.c contains the reduced testcase for the Fortran front-end miscompilation, and I don't need anymore to work with two stages at a time. Working in a gcc directory now will be like working in a non-bootstrapped build. make stage1-start cd gcc gdb --args ./cc1 -O2 -o - ../a.c ... fix bug in combine.c ... make cc1 ./cc1 -O2 -o - ../a.c ... seems fixed ... ./xgcc -B. -O2 -o test ../a.c ./test Ok, looks like I'm done. Since stage1 miscompiled stage2, I expect many if not all object files to change, and I cannot do a bubblestrap. There is no equivalent of `make restrap', so I manually delete stage2. cd .. rm -rf stage2-* stage1-powerpc* make bootstrap make -k check (It occurs now to me that restrap is easy to implement, so I will submit a patch as soon as the queue is exhausted). A few hours later... yay, bug fixed! Paolo
C++ parsing regression?
g++ no longer parses ScalarCode >(CflFunctor(omrot, vis_f))(scratch, I, cs, nue, v); correctly, but issues tramp3d-v4.cpp:53573: error: invalid declarator which can be fixed by putting parantheses around the decl. Was this change intended? It happened between r109062 and r109079, where the only cp/ changes were +2005-12-26 Mark Mitchell <[EMAIL PROTECTED]> + + PR c++/25439 + * decl.c (grokdeclarator): Remove dead code. + * ptree.c (cxx_print_xnode): Handle BASELINK. + * parser.c (make_id_declarator): Add sfk parameter. + (cp_parser_direct_declarator): Do not pass TYPE_DECLs to + make_id_declarator. + (cp_parser_declarator_id): Simplify BASELINKs here. + (cp_parser_member_declaration): Adjust calls to + make_id_declarator. + +2005-12-26 Mark Mitchell <[EMAIL PROTECTED]> + + PR c++/23171, c++/23172, c++/25417. + * typeck.c (build_unary_op): Create temporary variables for + compound literals whose addresses are taken. + * init.c (expand_aggr_init_1): Use COMPOUND_LITERAL_P. + * decl.c (reshape_init_vector): Likewise. + (reshape_init): Give it external linkage. + (check_initializer): Use COMPOUND_LITERAL_P. + (initialize_artificial_var): Allow the initializer to be a + CONSTRUCTOR. + * call.c (make_temporary_var_for_ref_to_temp): Use + create_temporary_var. + * cp-tree.h (COMPOUND_LITERAL_P): New macro. + (rehape_init): Declare. + * typeck2.c (digest_init): Use COMPOUND_LITERAL_P. + * semantics.c (finish_compound_literal): Use reshape_init. and the first one looks parsing related. Richard.
fake edges for const and pure functions
I just found this in tree-cfg.c; the comment is probably wrong with
respect to const and pure. What do you think?
/* Return true if we need to add fake edge to exit at statement T.
Helper function for tree_flow_call_edges_add. */
static bool
need_fake_edge_p (tree t)
{
tree call;
/* NORETURN and LONGJMP calls already have an edge to exit.
CONST and PURE calls do not need one.
We don't currently check for CONST and PURE here, although
it would be a good idea, because those attributes are
figured out from the RTL in mark_constant_function, and
the counter incrementation code from -fprofile-arcs
leads to different results from -fbranch-probabilities. */
call = get_call_expr_in (t);
if (call
&& !(call_expr_flags (call) & ECF_NORETURN))
return true;
if (TREE_CODE (t) == ASM_EXPR
&& (ASM_VOLATILE_P (t) || ASM_INPUT_P (t)))
return true;
return false;
}
Paolo
Re: -fpic no optimization...
> I was compiling LZMA SDK (http://www.7-zip.org/, LzmaDecode.c) and just > for curiosity I looked at output assembler. I noted that when PIC is > enabled (-fpic, Linux Intel) ebx is reserved to global pointer. However > LzmaDecode do not access any global data and do not call other functions > (no relocations at all) so why not use ebx register? -fpic make compiler > just not use ebx. I tried using different versions (gcc 3.4.4 from > Fedora Core 3 and 4.0.2 from Fedora Core 4) with same result. > I just tried same test with gcc 4.2.0 20051231 with same behavior. Frediano Ziglio
Re: [gnu.org #247501] Submitting to the Gnu Project
Hello, I filled and posted FSF assignment (with an employer disclaimer) back to FSF via mail half year ago. Did you received it ? Best Regards Tomas Bily > Hello, > > This email is to follow up on your communication with the Free Software > Foundation. Previously, you had expressed interest in contributing to > the GNU Project. If this is still the case please respond so that we > can move the process along. If you did not receive the assignment > please let us know and we will cheerfully mail out another. If you need > an employer disclaimer and did not receive one via email we will forward > you a copy. > > I apologize if this email reached you in error, but please let me know > so that I may remove you from the record. It too is possible that you > have completed your assignment process with the FSF, but have yet to be > removed from the list of outstanding assignments. If this is the case > please let me know so that I can update the record. > > > All the best, > Jonas Jacobson > Copyright Administrator > Free Software Foundation > 51 Franklin Street, Fifth Floor > Boston, MA 02110 > Phone +1-617-542-5942 > Fax +1-617-542-2652 >
Re: fake edges for const and pure functions
> I just found this in tree-cfg.c; the comment is probably wrong with
> respect to const and pure. What do you think?
Yes, it should be safe to remove the hack now when we do IPA profiling.
Thanks for noticing it ;)
Honza
>
> /* Return true if we need to add fake edge to exit at statement T.
> Helper function for tree_flow_call_edges_add. */
>
> static bool
> need_fake_edge_p (tree t)
> {
> tree call;
>
> /* NORETURN and LONGJMP calls already have an edge to exit.
> CONST and PURE calls do not need one.
> We don't currently check for CONST and PURE here, although
> it would be a good idea, because those attributes are
> figured out from the RTL in mark_constant_function, and
> the counter incrementation code from -fprofile-arcs
> leads to different results from -fbranch-probabilities. */
> call = get_call_expr_in (t);
> if (call
> && !(call_expr_flags (call) & ECF_NORETURN))
>return true;
>
> if (TREE_CODE (t) == ASM_EXPR
> && (ASM_VOLATILE_P (t) || ASM_INPUT_P (t)))
>return true;
>
> return false;
> }
>
> Paolo
gcc 4.0.2
Dear Sirs, Have you tried to build gcc 4.0.2 from the source on Windows XP Pro? Here is what I did. 1. Downloaded gcc-4.0.2.tar.gz. 2. Checked integrity of gcc-4.0.2.tar.gz using md5 and jacksum. 3. Downloaded MinGW-4.1.0.exe. 4. Installed gcc version 3.4.2 (mingw-special). 5. Downloded and installed msys 1.0.10. 6. Copied lib directory from c:/mingw to /home/akrivitsky1 (here msys notation is used). 7. unpacked gcc-4.0.2.tar.gz into /home/akrivitsky1/gcc-4.0.2 8. Within msys typed LIBRARY_PATH=/home/akrivitsky1/lib 9. Within msys mkdir mywin32 10. cd mywin32 11. Tryed several combinations of options and parameters of /home/akrivitsky1/gcc-4.0.2/configure 12. Tryed several combinations of make End result of all this is *begin /home/akrivitsky1/gcc-4.0.2/gcc/input.h: No such file or directory make[1]: *** [s-gtype] Error 1 make[1]: Leaving directory `/home/akrivitsky1/mywin32/gcc' make: *** [all-gcc] Error 2 **end for each combination of comfigure/make I tryed. Before configure and make /home/akrivitsky1/gcc-4.0.2/gcc/input.h existed. Manual copying this file to said directory does not do any good either. Can it be some kind of bug in some make/configure file from gcc 4.0.2 distribution? Can you please send me what is needed to be typed for configure and make to build gcc 4.0.2? Thank you very much. Regards, Anatoly
Regarding delayed branches and CFGs
hi, On a target that supports delayed branches, i have the following code generated by gcc-3.4.4: Before dbr_schedule: ~~~ 1- label1: 2- cmp r0,100 3- branch.eq label2 ... 4- move r1, 0 ... 5- label2: 6- cmp r1, 0 7- branch.eq label1 After dbr_schedule: ~~ 1- label1: 2- cmp r0,100 3- branch.eq.delay label3 6- cmp r1, 0 ... 4- move r1, 0 ... 6- cmp r1, 0 8- label3: 7- branch.eq label1 Thus the cmp instruction is moved to the branch's(3) delay slot, and the branch is redirected to a new label(8) to avoid redundant comparison. Now, the problem is that, in absence of a cfg based optimization after the delayed branch, i end up with a pair of useless move-cmp instructions (4,6) in the same basic block. I saw a thread on the list, discussing why cfg build cannot be repeated after the delayed branch scheduler has been run. So, what would be the best approach to handle this situation? Thanx in advance for any suggestions/hints regards saurabh
Re: [gnu.org #247501] Submitting to the Gnu Project
Tomas, On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > I filled and posted FSF assignment (with an employer disclaimer) back > to FSF via mail half year ago. Did you received it ? I found the following in the copyright file on the FSF network: GCC Tomas Bily United States 2005-07-28 Assigns past and future changes [EMAIL PROTECTED] ANY SuSe Prague 2005-07-26 Disclaims all past interest and for 5 years from the date of the disclaimer, in changes made to free software by Tomas Bily. The country appears to be wrong (since I believe you are Czech, not American), but apart from that everything looks okay (for the next 4.5) years. (I removed you year of birth and replaced it with "" above.) Gerald
Re: [gnu.org #247501] Submitting to the Gnu Project
Tomas, On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > I filled and posted FSF assignment (with an employer disclaimer) back > to FSF via mail half year ago. Did you received it ? I found the following in the copyright file on the FSF network: GCC Tomas Bily United States 2005-07-28 Assigns past and future changes [EMAIL PROTECTED] ANY SuSe Prague 2005-07-26 Disclaims all past interest and for 5 years from the date of the disclaimer, in changes made to free software by Tomas Bily. The country appears to be wrong (since I believe you are Czech, not American), but apart from that everything looks okay (for the next 4.5) years. (I removed you year of birth and replaced it with "" above.) Gerald
Re: [gnu.org #247501] Submitting to the Gnu Project
Tomas, On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > I filled and posted FSF assignment (with an employer disclaimer) back > to FSF via mail half year ago. Did you received it ? I found the following in the copyright file on the FSF network: GCC Tomas Bily United States 2005-07-28 Assigns past and future changes [EMAIL PROTECTED] ANY SuSe Prague 2005-07-26 Disclaims all past interest and for 5 years from the date of the disclaimer, in changes made to free software by Tomas Bily. The country appears to be wrong (since I believe you are Czech, not American), but apart from that everything looks okay (for the next 4.5) years. (I removed you year of birth and replaced it with "" above.) Gerald
Bootstrap failure on Linux/i686 in Ada
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bootstrap failed in stage 3 on building gprmake: ../../gnatmake -c -I../rts -I. - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada gprmake - --GCC="../../xgcc -B../../ -O2 -g -O2 -gnatpg -gnata" ../../xgcc -c -I./ -I../rts -I. - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada -B../../ -O2 -g - -O2 -gnatpg -gnata -I- /raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/gprmake.adb ../../xgcc -c -I./ -I../rts -I. - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada -B../../ -O2 -g - -O2 -gnatpg -gnata -I- /raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/makegpr.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) gnatmake: "/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/makegpr.adb" compilation error gmake[3]: *** [../../gprmake] Error 4 gmake[3]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/stage3-gcc/ada/tools' gmake[2]: *** [gnattools-native] Error 2 gmake[2]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/gnattools' gmake[1]: *** [all-gnattools] Error 2 gmake[1]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2' - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDuUxF3s6elE6CYeURAoD7AKCv5GtEBqr5/E5tjHYRwwcewdzgigCg0cNL lynthMiMOvNiH6j4AL83NCM= =FvR+ -END PGP SIGNATURE-
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
> From: Robert Dewar <[EMAIL PROTECTED]> > .. there is no requirement that optimization preserve the behavior of > undefined programs ... It is fine to argue that defining the semantics > is useful in a particular case, but arguing solely from the point of > view of trying to preserve observed behaviort is a poor argument. > > Indeed the point is that optimization is not changing the behavior, the > behavior is non-deterministic, and can change from one compilation to > the next even if optimization does not change. - observable program behavior is the only thing that's significant. - yes, it's understood that a language's specification may consider multiple program implementations having differing observable behaviors as being logically equivalent when their observable differences are restricted to differing implementations of under/undefined language semantics; however this does not imply observable behavior modifying optimizations are generally innocuous and/or desirable, as in fact any optimization which may alter a programs observable behavior which was otherwise deemed desirable is clearly arguably counterproductive, as neither observable behavior is warranted to be portable or more correct. - however as promised I'll abstain from further debate as the community seems satisfied with accepting the consequences of such optimizations.
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
Paul Schlie wrote: - however as promised I'll abstain from further debate as the community seems satisfied with accepting the consequences of such optimizations. I think you misunderstand, everyone agrees that defined and deterministic semantics are desirable, but also everyone (or perhaps I should say almost everyone) understands that there are situations where this requirement is too expensive. An obvious example is uninitialized variables, where in a language like C or Ada, it is considered to expensive (and not clearly desirable) to preinitialize all variables (though it is useful to have an option to do this, see pragmas Normalize_Scalars and Initialize_Scalars in Ada, the former intended for high integrity operation, and the latter for debugging purposes).
Re: C++ parsing regression?
Richard Guenther wrote: > g++ no longer parses > > ScalarCode >(CflFunctor(omrot, vis_f))(scratch, > I, cs, nue, v); > > correctly, but issues > > tramp3d-v4.cpp:53573: error: invalid declarator > > which can be fixed by putting parantheses around the decl. Was this > change intended? I'm not sure; please send me preprocessed source, and I will look into it. It's certainly possible that those changes broke something. What do you think the above code is supposed to mean? Are you declaring a constructor for CflFunctor, or an unnamed variable of type ScalarCode > or ? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc 4.0.2
Anatoly Krivitsky wrote: > > Have you tried to build gcc 4.0.2 from the source on > Windows XP Pro? > I recently built gcc-4.1 snapshot successfully on Windows XP. I will list down the steps I followed, they should work with the 4.0.2 version also. Note that gcc build instructions discourage building in the same directory where the gcc source code is exploded. Use a directory outside of that directory to build. 1) Start cmd.exe 2) cd E:\msys\1.0\home\ 3) md gcc 4) cd gcc 5) tar -xvzf gcc-4.1-20051223.tar.gz 6) mkdir gcc-obj 7) cd gcc-obj 8) set PATH=E:\mingw\bin;E:\msys\1.0\bin;%PATH%; 9) sh ../gcc-4.1-20051223/configure --host=mingw32 --build=mingw32 -- target=mingw32 --enable-threads --disable-nls --enable-optimize --enable-languag es=c,c++ --prefix=e:/mingw4 10) make Make will fail with an error - Makefile:1277 : target pattern contains no %. Stop. Edit E:\msys\1.0\home\gcc\gcc-obj\gcc\Makefile and change the line ORIGINAL_LD_FOR_TARGET = ./E:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/ld.exe to ORIGINAL_LD_FOR_TARGET = /mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/ld.exe Restart make and after build completes do a make install. You will have a gcc install in configured prefix. You then need to gunzip/untar the mingw-runtime, w32api etc. packages in the prefixed directory. Obviously, change paths in the above commands to reflect the actual paths and drives you are using. HTH Parag -- Sent from the gcc - Dev forum at Nabble.com: http://www.nabble.com/gcc-4.0.2-t837679.html#a2172990
Re: Bootstrap failure on Linux/i686 in Ada
Hi Rainer, this is PR24994: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 And is under investigation: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html Laurent On Mon, 2006-01-02 at 16:52 +0100, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bootstrap failed in stage 3 on building gprmake: > > ../../gnatmake -c -I../rts -I. > - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada gprmake > - --GCC="../../xgcc -B../../ -O2 -g -O2 -gnatpg -gnata" > ../../xgcc -c -I./ -I../rts -I. > - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada -B../../ > -O2 -g > - -O2 -gnatpg -gnata -I- > /raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/gprmake.adb > ../../xgcc -c -I./ -I../rts -I. > - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2/gcc/ada -B../../ > -O2 -g > - -O2 -gnatpg -gnata -I- > /raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/makegpr.adb > > raised STORAGE_ERROR : stack overflow (or erroneous memory access) > gnatmake: > "/raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/makegpr.adb" > compilation error > gmake[3]: *** [../../gprmake] Error 4 > gmake[3]: Leaving directory > `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/stage3-gcc/ada/tools' > gmake[2]: *** [gnattools-native] Error 2 > gmake[2]: Leaving directory > `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/gnattools' > gmake[1]: *** [all-gnattools] Error 2 > gmake[1]: Leaving directory > `/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2' > > > - -- > Rainer Emrich > TECOSIM GmbH > Im Eichsfeld 3 > 65428 Rüsselsheim > > Phone: +49(0)6142/8272 12 > Mobile: +49(0)163/56 949 20 > Fax.: +49(0)6142/8272 49 > Web: www.tecosim.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDuUxF3s6elE6CYeURAoD7AKCv5GtEBqr5/E5tjHYRwwcewdzgigCg0cNL > lynthMiMOvNiH6j4AL83NCM= > =FvR+ > -END PGP SIGNATURE- > >
Re: -fpic no optimization...
On Jan 1, 2006, at 9:26 AM, Frediano Ziglio wrote: I noted that when PIC is enabled (-fpic, Linux Intel) ebx is reserved to global pointer. However LzmaDecode do not access any global data and do not call other functions (no relocations at all) so why not use ebx register? This is a known issue and isn't likely to be fixed anytime soon... the details as to why are gory and beyond the scope of this email, though, we too would love it if someone fixed this.
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
On Dec 31, 2005, at 9:26 PM, Paul Schlie wrote: be able define NULL as being some value other than 0. Do you have a specific chip in mind you want to do this for? Why would you want to do this? How many users would benefit from having done this? - enable the specification of arithmetic pointer and integer overflow semantics, not limited to invoking an undefined or modulo results, as being able to support saturating integer arithmetic optimization seems increasingly attractive as signal processing becomes more pervasive. Yes, but you didn't answer my other two question. Anyway, what hardware does only saturating arithmetic? If it does both, would you want + to be saturating? If so, why? How would you then want to get non-saturating arithmetic? Saturating arithmetic is a good example of where the code should use a specialized form to denote the operation, and that form then makes the code completely portable, so, I cannot fathom why you'd want it in this class. What compilers do this today? What code bases do this today? If none and none, why would we want to? We don't yet have a clue why you want this, could you give us the real reason. Theoretic beauty? You wanna sell a chip that does this and have a compiler for it? You want to define a new language because you think it'd be cool? You want gcc to match the needs of DSP programmers better? - enable the specification of the result/behavior of a shift greater than the width of a operand This one I actually understand.
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
On Jan 1, 2006, at 9:57 AM, Paul Schlie wrote: - x[y] = 0; if (x[y]) y = y+1; And how does this differ from the portable code in which x points to volatile data? If none, what are the advantages in being able to write non-portable code that leaves the volatile out over standard conforming code with the volatile in?
Re: [gnu.org #247501] Submitting to the Gnu Project
Hi Gerald, > Tomas, > > On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > > I filled and posted FSF assignment (with an employer disclaimer) back > > to FSF via mail half year ago. Did you received it ? > > I found the following in the copyright file on the FSF network: > > GCC Tomas Bily United States 2005-07-28 > Assigns past and future changes > [EMAIL PROTECTED] > > ANY SuSe Prague 2005-07-26 > Disclaims all past interest and for 5 years from the date of the > disclaimer, in changes made to free software by Tomas Bily. > > The country appears to be wrong (since I believe you are Czech, not > American), but apart from that everything looks okay (for the next > 4.5) years. Yes, i am czech :). > (I removed you year of birth and replaced it with "" above.) > > Gerald > > > Tomas
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
> From: Mike Stump <[EMAIL PROTECTED]> >> On Dec 31, 2005, at 9:26 PM, Paul Schlie wrote: >> be able define NULL as being some value other than 0. > > Do you have a specific chip in mind you want to do this for? Why > would you want to do this? How many users would benefit from having > done this? - the avr maps it's register file starting at data address 0, as did the old TI 99xx family CPU's (now defunct), and possibly others? >> - enable the specification of arithmetic pointer and integer overflow >> semantics, not limited to invoking an undefined or modulo results, as >> being able to support saturating integer arithmetic optimization seems >> increasingly attractive as signal processing becomes more pervasive. > > Yes, but you didn't answer my other two question. Anyway, what > hardware does only saturating arithmetic? If it does both, would you > want + to be saturating? If so, why? How would you then want to get > non-saturating arithmetic? > > Saturating arithmetic is a good example of where the code should use > a specialized form to denote the operation, and that form then makes > the code completely portable, so, I cannot fathom why you'd want it > in this class. - as signed arithmetic overflow is undefined, it seems just as reasonable to define an implementation which supports signed saturating arithmetic as any other; as arguably signed integer saturating arithmetic may be considered more arithmetically consistent than signed 2's comp modular arithmetic is, and more similar to floating point overflow semantics than alternatives. (not good or bad, but just fact) > What compilers do this today? What code bases do this today? > > If none and none, why would we want to? - the question shouldn't be who does this today, but ideally: if more efficient, consistent, and behavior preserving target specific optimization is perceived as being useful, then why shouldn't such abilities be considered? > We don't yet have a clue why you want this, could you give us the > real reason. Theoretic beauty? You wanna sell a chip that does this > and have a compiler for it? You want to define a new language > because you think it'd be cool? You want gcc to match the needs of > DSP programmers better? - at the most basic level, I feel like I've too often needlessly wasted time debugging programs at one level of optimization, to only see a different behavior needlessly expressed at a different level of optimization (which I understand means something isn't portable, but isn't the correct way to inform one of non-portable code, but is one hell of a way to unknowingly interject bugs into a program which didn't exist at a different level of optimization); however if a compiler supported the means by which a target could define the semantics left undefined by a language, an optimizing compiler could then both satisfy the formal constrains of language, while simultaneously enabling target specific semantics to be supported, and preserved through optimization. (which seems like a win-win to me) >> - enable the specification of the result/behavior of a shift greater >> than the width of a operand > > This one I actually understand. >> - x[y] = 0; >> if (x[y]) y = y+1; > > And how does this differ from the portable code in which x points to > volatile data? If none, what are the advantages in being able to > write non-portable code that leaves the volatile out over standard > conforming code with the volatile in? - I'm not trying to defend such code, but believe if it were determinable that the dereference of x[y] were undefined for a particular value of y, the only behavior I perceive as being reasonable to presume, is that which has been defined by the target if not specifically designated by the language, otherwise no optimization is valid unless it's effect is known not be be logically observable thereby may be eliminated regardless of specified semantics (where undefined is the absents of any specification, including that specified as being undefined).
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 19 Dec 2005, Richard Henderson wrote: > I think that this is all complicated enough that we should > simply deny peepholing insns with RTX_FRAME_RELATED_P set. I was just bitten by the same behavior for define_split. Should the same go for define_splits and maybe also as a guard test for combine? Maybe a utility function to use by all insn transformations? brgds, H-P
Re: RFC: peephole vs RTX_FRAME_RELATED_P
Hans-Peter Nilsson <[EMAIL PROTECTED]> writes: > On Mon, 19 Dec 2005, Richard Henderson wrote: > > I think that this is all complicated enough that we should > > simply deny peepholing insns with RTX_FRAME_RELATED_P set. > > I was just bitten by the same behavior for define_split. > Should the same go for define_splits and maybe also as a guard > test for combine? Maybe a utility function to use by all insn > transformations? I wouldn't expect to see any insns with RTX_FRAME_RELATED_P set before the prologue and epilogue are threaded in the flow2 pass. So combine shouldn't be an issue. And flow2 calls split_all_insns before the prologue and epilogue insns are threaded. When did the bogus split happen? Ian
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
On 1/2/06, Paul Schlie <[EMAIL PROTECTED]> wrote: > - at the most basic level, I feel like I've too often needlessly wasted > time debugging programs at one level of optimization, to only see a > different behavior needlessly expressed at a different level of > optimization (which I understand means something isn't portable, but > isn't the correct way to inform one of non-portable code, but is one > hell of a way to unknowingly interject bugs into a program which didn't > exist at a different level of optimization); however if a compiler > supported the means by which a target could define the semantics left > undefined by a language, an optimizing compiler could then both satisfy > the formal constrains of language, while simultaneously enabling target > specific semantics to be supported, and preserved through optimization. > (which seems like a win-win to me) Okay, this makes sense to me now. If there were a switch that changed the language from ISO C to a very similar language that actually specified a fixed behavior for all the behaviors that ISO C says are unspecified or undefined, then you'd have a language that might not be possible to compile as efficiently in some cases, but in which every program had a unique correct behavior. (Setting aside inherently unpredictable things like threads and signals.) For example, the language would actually have to specify some default value for all variables, or require them to be assigned before their first use in a way that the compiler could statically verify (as in Java). This is what the Java folks were shooting for, if you ignore the non-determinism introduced by threads. Standard ML also specifies a particular result for all programs. If my copies of both those specs weren't still packed, I think I could actually find quotes from each where they state being fully defined as a goal. So I think it's clear there are a lot of people who think this is a worthwhile principle. Paul is combining this suggestion with the further idea that the unspecified and undefined behaviors could be tied down in a way comfortable for the particular target. I guess he's trying to reduce the performance impact. That concession would allow the changes in behavior that annoy him now when he switches optimization levels to re-appear when one switches targets. The opposite extreme to Paul's concession would be to eliminate all target-dependent characteristics from the language, including type size differences and alignment requirements, yielding a language which specified a unique correct result for all programs (again, setting aside threads and signals) on all targets. As ML and Java do. Or, there could be a middle ground: you could specify some characteristics (say, integral type sizes and wrap-around on overflow) for all targets, but leave others (say, pointer size and alignment) target-specific.
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 2 Jan 2006, Ian Lance Taylor wrote: > I wouldn't expect to see any insns with RTX_FRAME_RELATED_P set before > the prologue and epilogue are threaded in the flow2 pass. So combine > shouldn't be an issue. And flow2 calls split_all_insns before the > prologue and epilogue insns are threaded. When did the bogus split > happen? Huh, I emitted RTL prologue insns that were themselves candidates for splitting (without any transformations). I thought the same could happen for RTL transformations but it seems peephole2 (and stack adjustments, but that's not applicable to CRIS) was the only "real" candidate. So, there's just an undocumented implicit requirement that nothing emitted as RTL prologue (accidentally) matches a splitter. brgds, H-P
