FW: what happened to service routines like getarg, iargc, ... in gfortran
Hello, Recently I tried to install mpich-1.2.7 with gfortran (gcc-4.0.1) on a fedora core 4 (x86_64) : The configure for mpich fails for fortran, because getarg and iargc are missing. Now my question, g77 supported a lot of commonly used service routines, which are now missing or at least I did not find how I can migrate my old programs to gfortran. Many thanks in advance for your help. Take care, Winfrid Fujitsu Siemens Computers S CE DE PCO Süd Winfrid Tschiedel Domagkstrasse 28 80807 München Tel:: ++49-89-3222-1532 FAX: ++49-89-3222-329-1532 intranet : [EMAIL PROTECTED] internet: [EMAIL PROTECTED]
Question on accessing and using binfos
> Hello,
>
> I'm wondering if I can get information from here on how to use the
> binfo macros.
>
What are the binfo access functions for gcc 3.4.1? I'm having trouble
creating the html files for gcc and I've been told BINFO_BASE_BINFO and
BINFO_BASE_ITERATE, which I found on the onlinedocs, are only for the
latest gcc which I don't have yet.
> How should these macros be used? If class A is mother class to B with
> the assosciated trees being Atree and Btree repectively, does
> TYPE_BINFO(Btree) give Atree?
> Or should BINFO_BASE_BINFO(TYPE_BINFO(Btree)) give Atree?
> And what does BINFO_TYPE actually do? (sorry but I don't really
> understand the instructions on the webpage...)
>
> I would also like information on accessing trees from their types.
> A library acting as backend to GCC gives me access to a class C's
> tree, let's say Ctree.
> I would like to know if C is derived from D. normally I should do,
> same_type-p(Ctree, Dtree) {I guess...}
> but I don't have or don't know how to get the Dtree. I just know that
> the name of the class is D.
> Is there a macro for retrieving the tree representing a class from its
> name or any known way of doing such a thing?
>
> Thanks for any answers.
>
> Primrose
inserting instructions into prologue/epilogue
Hello! I am trying to add instructions into function prologue/epilogue. These instructions shall save and load "fixed" registers to avoid assembly. Register saving in the prologue appears to work. The restore code in the epilogue aborts in flow.c/propagate_one_insn with "Attempt to delete prologue/epilogue insn" unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats the proper fix. Then I used TARGET_ASM_FUNCTION_END_PROLOGUE to emit additional assembly code. However this hook is _only_ called if prologue/epilogue instructions are scheduled. Is that the expected behaviour? tm.texi doesn't mention this. I tried to get rid of TARGET_ASM_FUNCTION_END_PROLOGUE by emitting the loads as RTL, but then I also get flow.c aborts if prologue and epilogue are scheduled. It works when not scheduling. This is the load code: ref = gen_rtx_SYMBOL_REF (Pmode, "symbol"); emit_insn (gen_elf_high (reg, ref)); emit_insn (gen_elf_low (reg, reg, ref)); How do I prevent the aborts from flow? Any help appreciated. Gunther Nikl
Re: inserting instructions into prologue/epilogue
Gunther Nikl wrote: Hello! I am trying to add instructions into function prologue/epilogue. These instructions shall save and load "fixed" registers to avoid assembly. Register saving in the prologue appears to work. The restore code in the epilogue aborts in flow.c/propagate_one_insn with "Attempt to delete prologue/epilogue insn" unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats the proper fix. you can add a (USE reg) after the restore in the prologue. Then flow considers the register, and the preceding load, to be live at that point. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: inserting instructions into prologue/epilogue
Nathan Sidwell wrote: you can add a (USE reg) after the restore in the prologue. Then flow in the EPILOGUE, of course considers the register, and the preceding load, to be live at that point. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Need help creating a small test case for g++ 4.0.0 bug
Hi Janis, A belated reply to your message is below. Best regards, Paul Leopardi On Tue, 17 May 2005 03:23 am, Janis Johnson wrote: > On Sat, May 14, 2005 at 12:16:54PM +1000, Paul C. Leopardi wrote: > > Hi all, > > I originally posted these messages to gcc-help, but had no reply, so I am > > re-posting links to them here. > > > > I think I have found a bug in g++ 4.0.0, but need help in reporting it. > > Maintainers like their bug reports to include short test cases, but I > > don't know how to generate a short test case involving inlining. I > > discovered the original problem by compiling GluCat ( > > http://glucat.sf.net ) and the preprocessor output from a short GluCat > > test program contains over 66 000 lines of libstdc++, uBLAS and Glucat > > code. > > > > Can anyone help, or should I just file a bug report using the huge test > > case? > > The information in http://gcc.gnu.org/bugs/minimize.html might help. I have now downloaded, bootstapped and installed gcc 4.0.1. The bug in g++ optimization is still there. I've made an attempt to follow the instructions on minimizing test cases and have so far accomplished: wc of old preprocessed source: 99412 260586 2965538 peg01.ii wc of new preprocessed source: 69309 241979 2668391 peg01.ii As you can see, this is not much of a reduction. The bug I'm seeing keeps disappearing as I try to reduce the source code. It seems to be a subtle interaction between the Barton-Nackman trick, Boost uBLAS, GNU hash_map and the g++ flags -fstrict-aliasing and -finline-functions. If I try to eliminate any of these, the bug disappears. [ See http://en.wikipedia.org/wiki/Barton-Nackman ] So I seem to be left with a large ( >2.5MB ) preprocessed source file. Should I try to report the bug using this large file as a test case? Or maybe I could get one of the gcc developers interested in using GluCat as a test bed for detecting bugs in g++ ? I am planning to release GluCat 0.1.9 fairly soon in any case, using g++ -O3 -fno-strict-aliasing as a workaround. Since GluCat is a template library, the compiler flags are only used to build test programs, and as a guideline to users of the library. So the bug is not holding up GluCat. It's just that I'd like to see how a nightmare corner case bug like this gets fixed, and I'd like to contribute something to that fix, even though I don't know enough about gcc internals to provide a patch.
Re: inserting instructions into prologue/epilogue
On Wed, Aug 03, 2005 at 03:50:09PM +0100, Nathan Sidwell wrote: > Gunther Nikl wrote: > >I am trying to add instructions into function prologue/epilogue. These > >instructions shall save and load "fixed" registers to avoid assembly. > > > >Register saving in the prologue appears to work. The restore code in the > >epilogue aborts in flow.c/propagate_one_insn with > > > > "Attempt to delete prologue/epilogue insn" > > > >unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats > >the proper fix. > > you can add a (USE reg) after the restore in the prologue. Then flow > considers the register, and the preceding load, to be live at that point. Thank you. With "emit_insn (gen_rtx_USE (VOIDmode, reg))" the abort disappears. The same approach seems to fix the loads in the prologue. I hope that this is the correct solution. On Wed, Aug 03, 2005 at 03:53:21PM +0100, Nathan Sidwell wrote: > Nathan Sidwell wrote: > > >you can add a (USE reg) after the restore in the prologue. Then flow > in the EPILOGUE, of course I wouldn't have notice this mistake without your mail. Thank you for the help. Gunther > >considers the register, and the preceding load, to be live at that point.
Re: Need help creating a small test case for g++ 4.0.0 bug
"Paul C. Leopardi" <[EMAIL PROTECTED]> wrote: > So I seem to be left with a large ( >2.5MB ) preprocessed source file. Should > I try to report the bug using this large file as a test case? Sure. But you might want to try using an automated tool to reduce the test case first. There's one called delta (or maybe there are several by that name, I'm not sure) that can do it. I haven't tried them myself yet, but see: Original implementation: http://www.st.cs.uni-sb.de/dd/ http://programming.newsforge.com/article.pl?sid=05/06/30/1549248&from=rss http://www.stanford.edu/class/cs295/asgns/asgn1/asgn.pdf 2nd implementation?: http://www.cs.berkeley.edu/~dsw/ -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Need help creating a small test case for g++ 4.0.0 bug
2nd implementation?: http://www.cs.berkeley.edu/~dsw/ This is what we all use, AFAIK :)
Re: Need help creating a small test case for g++ 4.0.0 bug
Paul Leopardi wrote: > I have now downloaded, bootstapped and installed gcc 4.0.1. The bug in g++ > optimization is still there. I've made an attempt to follow the instructions > on minimizing test cases and have so far accomplished: > wc of old preprocessed source: > 99412 260586 2965538 peg01.ii > wc of new preprocessed source: > 69309 241979 2668391 peg01.ii > As you can see, this is not much of a reduction. The bug I'm seeing keeps > disappearing as I try to reduce the source code. It seems to be a subtle > interaction between the Barton-Nackman trick, Boost uBLAS, GNU hash_map and > the g++ flags -fstrict-aliasing and -finline-functions. If I try to eliminate > any of these, the bug disappears. You might want to try a recent snapshot of gcc 4.0.2, first. Two aliasing bugs got fixed after the 4.0.1 release: http://gcc.gnu.org/PR22591 http://gcc.gnu.org/PR23192 The first even caused std::list::swap to be miscompiled. Regards, Volker
Re: Request to reopen a PR
On Wed, Aug 03, 2005 at 02:56:08PM +1000, Greg Schafer wrote: > Could somebody with appropriate privilege please do me a favor and reopen > the following bugzilla PR? > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003 Volker re-opened it.
Re: memcpy to an unaligned address
> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes: Shaun> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote: >> It sounds like the workaround is to avoid memcpy, and just use >> variable assignment. Alternatively, cast the pointers to char*, >> which should force memcpy to do the right thing. Ugh. Shaun> I swear originally, back in the gcc 2.95 days, I used memcpy Shaun> because the memcpy function checked for unaligned pointers, Shaun> whereas storing to and loading from unaligned variables Shaun> generated a simple store/load instruction which wouldn't Shaun> work. It seems the tables have turned and the exact opposite Shaun> is true now with gcc 4, where memcpy doesn't work, but Shaun> unaligned variables do. I believe gcc 3 behaved the same as Shaun> gcc 2 -- memcpy worked, unaligned variables didn't work. Can Shaun> someone confirm this summary is correct? I'm pretty sure I have used unaligned load/store with gcc 2 as well as 3 and it works correctly. Certainly it should work correctly. If you tell GCC to pack stuff, and it does (assigning odd offsets in the process) then GCC is responsible for generating code to cope with that. All this assuming you're not playing games with pointer arithmetic to generate pointers that are less aligned than what GCC is entitled to assume. If you saw something else, that would have been a GCC bug. paul
Re: Question on accessing and using binfos
<[EMAIL PROTECTED]> writes: > > I'm wondering if I can get information from here on how to use the > > binfo macros. > > > What are the binfo access functions for gcc 3.4.1? I'm having trouble > creating the html files for gcc and I've been told BINFO_BASE_BINFO and > BINFO_BASE_ITERATE, which I found on the onlinedocs, are only for the > latest gcc which I don't have yet. The internal documentation for gcc 3.4.1 comes with the source code, and you can build it by doing, e.g., 'make html' or 'make dvi'. Look for the file(s) named gccint. In there you will see documentation for TYPE_BINFO, BINFO_BASETYPES, etc. Hope that helps. Ian
non canonical tree in java
java is creating a COMPONENT_REF node where the first operand is a RECORD_TYPE, rather than an expresion or DECL node. This is created at java/class.c:1014 prim_class = lookup_class (get_identifier (prim_class_name)); return build3 (COMPONENT_REF, NULL_TREE, prim_class, TYPE_identifier_node, NULL_TREE); here PRIM_CLASS is the RECORD_TYPE of the class. This usage disagrees with the requirements for a COMPONENT_REF in tree.def /* Value is structure or union component. Operand 0 is the structure or union (an expression). Operand 1 is the field (a node of type FIELD_DECL). Operand 2, if present, is the value of DECL_FIELD_OFFSET, measured in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT. */ DEFTREECODE (COMPONENT_REF, "component_ref", tcc_reference, 3) it is interfering with some cleanups I'm trying to do. What would be the best way of making java compliant? Have lookup_class return a suitable VAR_DECL node? I'm not sure where this then gets used ... nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: inserting instructions into prologue/epilogue
Gunther Nikl <[EMAIL PROTECTED]> writes: > I am trying to add instructions into function prologue/epilogue. These > instructions shall save and load "fixed" registers to avoid assembly. > > Register saving in the prologue appears to work. The restore code in the > epilogue aborts in flow.c/propagate_one_insn with > > "Attempt to delete prologue/epilogue insn" > > unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats > the proper fix. As Nathan said, you can add a USE. Or in some cases the correct fix is to define EPILOGUE_USES and/or EH_USES. In some cases this error message can indicate a bug in the prologue/epilogue code. For example, if you accidentally try to save two different registers into the same stack slot, flow will cleverly try to delete the first store, and then cleverly notice that it is deleting a prologue insn. Similarly if you accidentally save a register into a stack slot which is being used for a temporary variable. Ian
Re: non canonical tree in java
> > java is creating a COMPONENT_REF node where the first operand is a > RECORD_TYPE, > rather than an expresion or DECL node. This is created at java/class.c:1014 > > prim_class = lookup_class (get_identifier (prim_class_name)); > return build3 (COMPONENT_REF, NULL_TREE, >prim_class, TYPE_identifier_node, NULL_TREE); > > here PRIM_CLASS is the RECORD_TYPE of the class. This usage disagrees with > the > requirements for a COMPONENT_REF in tree.def > /* Value is structure or union component. > Operand 0 is the structure or union (an expression). > Operand 1 is the field (a node of type FIELD_DECL). > Operand 2, if present, is the value of DECL_FIELD_OFFSET, measured > in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT. */ > DEFTREECODE (COMPONENT_REF, "component_ref", tcc_reference, 3) > > it is interfering with some cleanups I'm trying to do. What would be the > best > way of making java compliant? Have lookup_class return a suitable VAR_DECL > node? I'm not sure where this then gets used ... The java front-end later on replaces prim_class with the correct tree, witness how the type of COMPONENT_REF is NULL. -- Pinski
Re: Wrong ChangeLog entries
Giovanni Bajo wrote: Mark, - with your commit for PR 20142, you also committed a hunk to name-lookup.c which is not described in the ChangeLog. It is also unclear whether it is effectively need for that PR or not, but nonetheless it went in, so the entry should probably be fixed I wanted you to know I'm not ignoring this email. I've not gotten to it yet, but I will soon. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: memcpy to an unaligned address
On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote: > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > > Yes, this is a compiler bug in the expansion of memcpy, please file a > > > bug report. The solution is for the compiler to notice the memory > > > alignment of the destination and `do-the-right-thing' when it isn't > > > aligned. > > > > No it is not, once you take the address (which should be rejected), it > > is of type "unsigned int *" and not unaligned variable, passing it to > > memcpy assumes the type alignment is the natural alignment. > > That argument doesn't make sense to me. It is nevertheless correct. Examine all of the parts of the expression. In particular, "&s->b". What type does it have? In an ideal world, it would be "pointer to unaligned integer". But we have no such type in our type system, so it is "pointer to integer". This expression is ONLY THEN passed to memcpy. At which point we query the argument for its alignment, and get the non-intuitive result. If you instead pass "s" to memcpy, you should get the correct unaligned copy. If that isn't happening, that's a bug. r~
Re: non canonical tree in java
Andrew Pinski wrote: The java front-end later on replaces prim_class with the correct tree, witness how the type of COMPONENT_REF is NULL. where does this happen? do you happen to know? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: inserting instructions into prologue/epilogue
On Wed, Aug 03, 2005 at 05:28:43PM +0200, Gunther Nikl wrote: > Thank you. With "emit_insn (gen_rtx_USE (VOIDmode, reg))" the abort > disappears. The same approach seems to fix the loads in the prologue. > I hope that this is the correct solution. No, it isn't. Your problem is that you havn't properly described the lifetime of these fixed registers. That's why they are being considered dead by flow. You probably need to modify CALL_USED_REGISTERS or CALL_REALLY_USED_REGISTERS. r~
Re: memcpy to an unaligned address
On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote: > It is nevertheless correct. Examine all of the parts of the expression. > > In particular, "&s->b". What type does it have? In an ideal world, it > would be "pointer to unaligned integer". But we have no such type in > our type system, so it is "pointer to integer". This expression is ONLY > THEN passed to memcpy. At which point we query the argument for its > alignment, and get the non-intuitive result. > > If you instead pass "s" to memcpy, you should get the correct unaligned > copy. If that isn't happening, that's a bug. I'm not sure I understood the last line. s is a structure, and its address is aligned. How would you pass it to memcpy, and why would it generate an unaligned copy? Cheers, Shaun
Re: non canonical tree in java
On Aug 3, 2005, at 2:05 PM, Nathan Sidwell wrote: Andrew Pinski wrote: The java front-end later on replaces prim_class with the correct tree, witness how the type of COMPONENT_REF is NULL. where does this happen? do you happen to know? Happens in java_complete_lhs in parse.y: case COMPONENT_REF: /* The first step in the re-write of qualified name handling. FIXME. So far, this is only to support PRIMTYPE.class -> PRIMCLASS.TYPE. */ TREE_OPERAND (node, 0) = java_complete_tree (TREE_OPERAND (node, 0)); -- Pinski
RE: memcpy to an unaligned address
Original Message >From: Shaun Jackman >Sent: 03 August 2005 19:15 > On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote: >> It is nevertheless correct. Examine all of the parts of the expression. >> >> In particular, "&s->b". What type does it have? In an ideal world, it >> would be "pointer to unaligned integer". But we have no such type in >> our type system, so it is "pointer to integer". This expression is ONLY >> THEN passed to memcpy. At which point we query the argument for its >> alignment, and get the non-intuitive result. >> >> If you instead pass "s" to memcpy, you should get the correct unaligned >> copy. If that isn't happening, that's a bug. > > I'm not sure I understood the last line. s is a structure, Not if "&s->b" makes any sense it isn't! cheers, DaveK -- Can't think of a witty .sigline today
Re: i_am_not_a_leaf() and -fno-unit-at-a-time
On Mon, 1 Aug 2005, Roland McGrath wrote: > initfini.c needs -fno-unit-at-a-time. It's not a normal compilation, but a > special hack for generating assembly fragments. The development libc uses > the flag for that file. I see now that the powerpc32 and powerpc64 Makefiles are overriding the default CFLAGS-initfini.s. I'll submit a patch. Thanks, Dwayne -- Dwayne Grant McConnell <[EMAIL PROTECTED]> Lotus Notes: Dwayne McConnell/Austin/[EMAIL PROTECTED]
Re: memcpy to an unaligned address
On Wed, Aug 03, 2005 at 12:15:05PM -0600, Shaun Jackman wrote: > I'm not sure I understood the last line. s is a structure, and its > address is aligned. How would you pass it to memcpy, and why would it > generate an unaligned copy? In the example I was replying to, S is a pointer to a structure, and it wasn't aligned. r~
G++ Modification Question
Hi all,
A while ago I attempted to make a modification to gcc 4.0 before it
was released. I attempted to create a modification that would allow me
to document all exceptions that are eithre thrown directly by a
function/method or that could propagate through a function/method. I ran
into a few problems along the way and this email is to ask a few
questions about gcc internals and better ways of coding in gcc so that I
can re-write this module to work correctly. (Sorry it is so long)
The modification I made to the C++ front end would parse the
global_namespace tree in the function cp_parser_translation_unit (found
in cp/parser.c) and create a database that maps a function/method to all
calls it made to other functions/methods and also a list of all
exceptions thrown directly by it. This database file was appended to for
each run of g++ and so after compiling a whole project the database
would(Should) contain the details for all methods in that project. I
then wrote a post-processing tool that went through the database and
generated a list of all exceptions that could propagate through a
particular function/method and also a seperate list of all exceptions
that would be thrown directly by the method.
In concept it worked, but my implementation of the tree parser did not
always work... A simple problem was that if I was to compile a small
file like:
---main.cpp---
void Function1();
void Function2();
int main()
{
Function1();
return 0;
}
void Function1()
{
throw 1;
}
void Function2()
{
throw 2;
}
Then the database would contain the information as expected for
Function1() but not for Function2(). The parser would come across a
definition for funciton 2 but there was no function body segment in the
tree for me to process and find out if it threw exceptions or called
other functions. This problem also seemed to occurr for all library
files I compiled. Is this some optimisation done by gcc and is there
another place where I can get access to a global tree that represents
ALL source code that has been parsed?
Also I was wondering if I was parsing the best tree for this problem.
The tree I was parsing was the tree found in the variable:
global_namespace
in the file:
cp/parser.c
in the function:
static bool cp_parser_translation_unit(cp_parser* parser)
just after the call to:
finish_translation_unit();
Another problem with the method I was using is that some of the tree
nodes that I expected to find in the tree were not avaliable, it was as
if they had already been translated to more primitive node types. For
example I did not see any tree nodes of type:
EH_SPEC_BLOCK
TRY_BLOCK
THROW_EXPR
EH_FILTER_EXPR
CATCH_EXPR
(Note I could be wrong about some of those expressions. I do however
remember that instead of getting a THROW_EXPR I had to search for calls
to the __cxa_throw() function to know when an exception was thrown. I
cant remember how I handled the try/catch blocks though I did).
I would like to re-write this code at some point and I am looking for
some pointers on ways of doing things better/differently. In particular
I would like to know if the method I was using as described above is
fine, or if there is a better tree to parse to get the information I
need or a better place to process the tree from.
If anyone is able to help me or even point me to the place where I can
get more help on this then I would greatly appreciate it.
I feel that a tool which enables me to see what exceptions can possibly
propagate through what methods could be very useful. It could also warn
of exceptions that could possibly propagate through methods whose
exception specification block do not support it. I was also looking at
modifying doxygen to automatically import this data into its
documentation, but that is another topic.
Thanks,
Brendon.
does -fstack-protector work for gcc 4.1 on Darwin 8?
Does anyone know if the -fstack-protector option in gcc 4.1 branch works on Darwin 8 (Tiger)? I can compile binaries with it but I'm not sure how to test its functionality. Also, this is based on IBM's ProPolice code, right? Jack
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
On Aug 3, 2005, at 5:48 PM, Jack Howarth wrote: Does anyone know if the -fstack-protector option in gcc 4.1 branch works on Darwin 8 (Tiger)? I can compile binaries with it but I'm not sure how to test its functionality. Also, this is based on IBM's ProPolice code, right? I'm surprised you could compile code until today - it wouldn't link the ssp libraries in... Anyhow, it seems to work in my limited testing after I checked in a couple of patches. -eric
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
On Wed, Aug 03, 2005 at 08:48:46PM -0400, Jack Howarth wrote: > Also, this is based on IBM's ProPolice code, right? Logically. It's a complete rewrite. r~
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Eric, Well what I have is a gfortran 4.1 branch fink package built using the 20050728 cvs with the new cray pointer patches donated by LANL. What I am trying to do is the following. I have been trying to build xplor-nih (which is a mix of c, c++ and fortran) with gfortran (it works okay with g77 or xlf). The new problem I have run into is some stack and heap corruption with both gfortran from 4.0 and 4.1 branch. The current suspect is the new cray pointer patches for Fortran which provide the necessary LOC intrinsic. My hope is that if compile xplor-nih with -fstack-protector on the fortran code when the stack is going to be corrupted it will throw a runtime error thus identify the culprit. Does this sound like a valid use of -fstack-protector? Jack ps As a test I built the cp_test.f90 cray pointer test program under gfortran with -fstack-protector. The resulting program passed its tests but I have no idea if that means the stack protector code itself was functional.
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Richard, Do you think I should be able to build gcc itself with the -fstack-protector flag and what is the most appropriate way to achieve that (ie brute force using a CFLAG or some configure flag)? I am interested in doing this so that I can have a libgfortran built with -fstack-protector to try to track down a potential stack corruption problem. Thanks in advance for any advice. Jack
Re: FW: what happened to service routines like getarg, iargc, ... in gfortran
[EMAIL PROTECTED] wrote: Recently I tried to install mpich-1.2.7 with gfortran (gcc-4.0.1) on a fedora core 4 (x86_64) : The configure for mpich fails for fortran, because getarg and iargc are missing. Now my question, g77 supported a lot of commonly used service routines, which are now missing or at least I did not find how I can migrate my old programs to gfortran. There is a meta bug tracking g77 features missing in gfortran. This is PR 19292 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292 This contains a list of missing service routines. The getarg/iargc problem in particular is PR 15665. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15665 This PR was fixed last year, and the patches fixing it are in gcc-4.0.1. It isn't clear why you are having a problem. You could maybe check that the configure script is correctly linking with the libgfortran library. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
General problem with x86 and PIC
Hi everyone, I've filed #23224, which outlines some pretty substantial problems with PIC on x86 targets (at least 2). This was all tested on 3.4.4, but very similar, if not exact, failures exist on the head of the 3_4-branch, and on the 4_0-branch too. I havent tried top-of-tree. I doubt this is fixed there either. If I can help at all, please let me know. I can produce any kind of assembly / compiler pass dumps required to help anyone who may understand all of this. TIA. Kean
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
On Wed, Aug 03, 2005 at 09:39:13PM -0400, Jack Howarth wrote: > Do you think I should be able to build gcc itself with the > -fstack-protector flag and what is the most appropriate way to > achieve that (ie brute force using a CFLAG or some configure > flag)? Considering that I don't think that self-building with -fstack-protector will ever be common, I don't think we ought to spend too many brain cells on this. The only way to bootstrap with -fstack-protector without existing support in libc is to use a top-level bootstrap. That said, I don't think this really addresses what you want to accomplish... > I am interested in doing this so that I can have a > libgfortran built with -fstack-protector to try to track down > a potential stack corruption problem. Thanks in advance for any > advice. This should be as simple as make all-gcc make all-target-libssp make CFLAGS_FOR_TARGET='-O -g -fstack-protector-all' all-target-libgfortran and then explicitly build your test program with -fstack-protector-all so that the right libraries get linked in. r~
Re: -b vs -bundle
Jack Howarth wrote: In compiling xplor-nih under the gcc/g++ of 4.1 branch instead of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's compiler I can have a Makefile entry like... This is PR 21366. You can always work around this by using -Wl,-bundle, which is the FSF solution to handling linker flags. Or don't put -bundle first on the command line. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: memcpy to an unaligned address
Richard Henderson <[EMAIL PROTECTED]> writes: > On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote: > > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > > > > Yes, this is a compiler bug in the expansion of memcpy, please file a > > > > bug report. The solution is for the compiler to notice the memory > > > > alignment of the destination and `do-the-right-thing' when it isn't > > > > aligned. > > > > > > No it is not, once you take the address (which should be rejected), it > > > is of type "unsigned int *" and not unaligned variable, passing it to > > > memcpy assumes the type alignment is the natural alignment. > > > > That argument doesn't make sense to me. > > It is nevertheless correct. Examine all of the parts of the expression. > > In particular, "&s->b". What type does it have? In an ideal world, it > would be "pointer to unaligned integer". But we have no such type in > our type system, so it is "pointer to integer". This expression is ONLY > THEN passed to memcpy. At which point we query the argument for its > alignment, and get the non-intuitive result. That's a good explanation for what gcc is doing, and I do now understand better than I did before. But I thought Andrew was arguing that gcc's behaviour is correct, and is not a compiler bug. I still think that gcc's behaviour here is not correct. It is clear that if gcc did not open code memcpy, the right thing would happen. If gcc open codes memcpy in such a way that it makes an incorrect assumption about alignment, for whatever reason, I think that is a bug in the compiler. And so, since I think this is a bug which we want to fix, and since we obviously want gcc to open code memcpy, I think that gcc has to somehow notice the memory alignments involved. Ian
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Richard, Is there some sample code that one can use to test the functionality of the code generated by -fstack-protector? Also, if one has a buggy program that is corrupting the stack, what is the expected behavior of this program when compiled with the stack protection code? Should it always abort at runtime with a userful error message or will it manage to suppress the stack corruption and keep on running. I was hoping to use the stack protection code as way to flag the position of offending code that was corrupting the stack rather than mask the corruption itself. Thanks in advance for any clarifications. Jack
RE: FW: what happened to service routines like getarg, iargc, ... in gfortran
Hello James, Thanks for the information - I have now to report the problem to bugzilla ( redhat ), because I used their build. Just an additional question - those routines are missing in the online documentation ( http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gfortran/ ) In the previous manual ( http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/ ) these routines where in chapter 8.11 described. Cheers, Winfrid Fujitsu Siemens Computers SMCS G LE PCO Süd Winfrid Tschiedel Domagkstrasse 28 80807 München Tel:: ++49-89-3222-1532 FAX: ++49-89-3222-329-1532 intranet: [EMAIL PROTECTED] internet: [EMAIL PROTECTED] -Original Message- From: James E Wilson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 04, 2005 5:01 AM To: Tschiedel, Winfrid Cc: gcc@gcc.gnu.org Subject: Re: FW: what happened to service routines like getarg, iargc, ... in gfortran [EMAIL PROTECTED] wrote: > Recently I tried to install mpich-1.2.7 with gfortran (gcc-4.0.1) on a fedora > core 4 (x86_64) : > The configure for mpich fails for fortran, because getarg and iargc are > missing. > Now my question, g77 supported a lot of commonly used service routines, which > are now missing or at least I did not find how I can migrate my old programs > to gfortran. There is a meta bug tracking g77 features missing in gfortran. This is PR 19292 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292 This contains a list of missing service routines. The getarg/iargc problem in particular is PR 15665. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15665 This PR was fixed last year, and the patches fixing it are in gcc-4.0.1. It isn't clear why you are having a problem. You could maybe check that the configure script is correctly linking with the libgfortran library. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
ICE hunting in gcc-4.1
Geez, 'delta' from http://www.cs.berkeley.edu/~dsw really does seem to make it easy to track down near-minimal testcases for ICEs. It's tempting to continually beat the crap out of gcc-4.1 snapshots by compiling all the sources I can find, then for each ICE that occurs, using delta to find a minimal testcase, and reporting it to bugzilla if it's not already there. Would that be useful, or is it overkill? -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: ICE hunting in gcc-4.1
Would that be useful, or is it overkill? Very useful. Though if you can occasionally go back through them to verify they're still bugs it'd be appreciated. -eric
Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20
[EMAIL PROTECTED] /local/tmp/gcc-3.4.4# ./config.guess hppa1.1-hp-hpux10.20 [EMAIL PROTECTED] /local/tmp/gcc-3.4.4/objdir# gcc -v Reading specs from /local/opt/gcc-3.4.4/lib/gcc/hppa1.1-hp-hpux10.20/3.4.4/specs Configured with: ../configure --disable-nls --prefix=/local/opt/gcc-3.4.4 --with-as=/opt/binutils/bin/as --with-gnu-as Thread model: single gcc version 3.4.4 Used full distribution + make bootstrap. Used egcs-2.91.57 and binutils-2.11.2 to compile gcc. I'm unable to make test cases since this host don't have tcl or X-headers for compiling tcl. -Frank.
