Re: What is really a new line in most compilers
Just a nit: 5 years ago that was true. Now \n is "native" Was that part of the OS/X migration, or otherwise? Just curious. Part of the migration. OS X /is/ unix. Ok, I'm sure that's an inaccurate statement and I trust the more experienced Apple guys here will gently correct me. But it really is... ;-) It is quite accurate to say that OS X is Unix, more precisely BSD given its NextSTEP ancestry (for example 10.2 did not even have the poll(2) system call, which is typically a SysV thing). Unfortunately, GUI programs such as TextEdit seem not to know this, and will still produce text files with bare CRs in them. But if all you use is Emacs, vim, Eclipse, terminal windows, etc. (as in my case) you can assume all your files have \n-terminated lines. Paolo
Emit insns in the preparation statements of define_expand
Hello,
I have a doubt here about define_expand and would be appreciated for
your any help. The internals say,
Usually these statements prepare temporary registers for use as
internal operands in the RTL template, but they can also generate RTL
insns directly by calling routines such as emit_insn, etc. Any such
insns precede the ones that come from the RTL template.
Well, here is the codes from mips_legitimize_move function in mips.c.
if (!register_operand (dest, mode) && !register_operand (src, mode))
{
emit_move_insn (dest, force_reg (mode, src));
return true;
}
Here is from mips.md,
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "" ""))]
""
{
if (mips_legitimize_move (SImode, operands[0], operands[1]))
DONE;
...
}
I think the function is to guarantee that there is at least one
register operand.
So if it's not, it will firstly load src into a register. But I think
it will be enough
for the function to just load src into a register. That is to say the
code should
be
if (!register_operand (dest, mode) && !register_operand (src, mode))
{
src=force_reg (mode, src);
return true;
}
I think since emit_move_insn (dest, force_reg (mode, src)) precedes
the rtl template
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "" ""))]
Then they are overlapped. There will be two move insns.
Thanks.
Eric.
Emit insns in the preparation statements of define_expand
Hey, It's very sorry. I have just found the answer just in the context. It's a so stupid question. DONE Use the DONE macro to end RTL generation for the pattern. The only RTL insns resulting from the pattern on this occasion will be those already emitted by explicit calls to emit_insn within the preparation statements; the RTL template will not be generated. No need to reply for saving your time. Thank. Eric
Re: backslash whitespace newline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Oct 26, 2005 at 02:22:55AM -0700, Kean Johnston wrote: > If you're working in an ISO9000 environment where every single source > line change is tracked by a rather burdensome process, the last thing > you want to do is invoke that process for some source base simply > because the new compiler you are moving to behaves differently to the > last 5 compilers you used. If ISO 9000 is more than just a rubber stamp and instead represents an actual commitment to Total Quality, the difference in behaviour between compilers would be a signal into the management system that something is amiss: that there is a particular quality problem with the code base (misunderstanding of the language standard) and that it needs to be fixed. Also, if a sed script that modifies comments is too great a burden to bear for such a beaurocracy, then using a different compiler should be even more of a red-tape jungle. If it isn't, the management system is broken and you might as well not bother with all those burdensome processes anymore - they're not doing you any good. My vote: I don't like surprises, and I'd like this code: int x; // variable x \\ int y; // variable y \\ to do exactly the same as this code: int x; // variable x \\ int y; // variable y \\ even if that behaviour is not the intent of the programmer. I want to be able to print out the code and review it in bed at night and be able to figure out why my code is broken (clobbering global variable due to continued C++-style comment). BTW is GCC's purpose to be a free (speech) compiler, or to dominate "the market"? If a company is too half-hearted about using GCC that they punt it with "it doesn't work" without further scrutiny, then I fail to see why (FSF) GCC should pander to their needs. But heck, if they paid me to do it I'd also hack up a patch that puts this under control of the command line and try to feed it into FSF GCC. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/ iD8DBQFDYJfDwyMv24BBd/gRAr1MAJ4tz4aSO34pDPTvUkB0lLkUBUpr8QCcDj2/ 1dFVqJCrPhzGj+IjUhbjTME= =b3cM -END PGP SIGNATURE-
Re: backslash whitespace newline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Oct 26, 2005 at 03:43:15PM -0700, Eric Christopher wrote: > >Don't you think it is reasonable to fix horrible coding errors like > >this, you are just asking for maintenance problems. In the short > >term, kludging may make sense, in the long term it sounds a bad idea > >to keep such non-portable code around. > > The problem is that it's portable to every other compiler we've > tested. I am curious what icc and xlc do, but those are the only two > not tested. s/portable/happens to work/g? I can understand that, all other things being equal, we (FSFians and the Appleanians) would rather have that one more big codebase building with GCC than not. All other things are *not* equal, alas; it would be a change we make *at the expense of* some other set of interests. Maybe GCC needs -fi-know-my-code-is-broken-but-i-and-wont-fix-it=0x29481 that sets a bitmap of alternate behaviours to pander to what "all other compilers" (or rather, some subset of that) happen to do right now. Can we break the impasse by having the behaviour under control of the command line, and issuing a warning whenever a backslash appears at the end of a C++-style comment - a risky construct in general? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/ iD8DBQFDYJ5DwyMv24BBd/gRAkjLAJoDvEpHDfRIPanYqZLeuV6cneLJqACeLm9k NuoS1l3t5HgwShKs415zn2A= =tpRY -END PGP SIGNATURE-
Re: backslash whitespace newline
Bernd Jendrissek wrote: My vote: I don't like surprises, and I'd like this code: int x; // variable x \\ int y; // variable y \\ to do exactly the same as this code: int x; // variable x \\ int y; // variable y \\ even if that behaviour is not the intent of the programmer. But really that's a comment on the standard. The standard unfortunately does not agree with your likes and dislikes. I think I like the gcc behavior better in a way, because it points out to the programmer that the above expectation is incorrect. I really think the standard is wrong here By the way, I think an excellent coding standard to follow is to completely forbid trailing spaces in all source code (we enforce this for both Ada and C code in the GNAT front end). We also forbid tabs in Ada code (but not in C code, due to fierce pressure from the C folks here, claiming that gcc style requires the tabs) for the same reason (white space changes not visible in printed and displayed copies are a potential menace -- e.g. in generating bogus mismatches for various tools).
Re: backslash whitespace newline
On 2005-10-26, Eric Christopher <[EMAIL PROTECTED]> wrote: > The problem is that it's portable to every other compiler we've > tested. I am curious what icc and xlc do, but those are the only > two not tested. I've just checked icc and it follows the croud (i.e. it treats "backslash space newline" differently to "backslash newline"). Cheers, Olly
Backlash newline newline backlash whiskey tango foxtrot
Are you guys done trying to decide what color to paint this bikeshed yet? If not, I suggest maroon (http://maroon.bikeshed.com), or maybe aquamarine (http://aquamarine.bikeshed.com). I believe every opinion anyone could ever have about this issue has been put forth, and nobody on either side has been convinced of anything, other than that the other side just doesn't get it. I think we lost sight of reality when someone implied that *this* was the issue that was holding back 9 million lines of source code never tested on gcc from working on gcc. I'd be incredibly surprised if, with 9 million lines of source code never before tested on gcc, the only thing that stops it from compiling under gcc is .. whitespace. If you guys step back and look from the big picture of GCC, the question of what we in the situation presented is such an insignificantly small issue that you'd need a electron microscope to see it. Which is invariably why it has generated so much discussion. At this point, i believe everyone should just shut up (since nobody is offering anything new *at all*), someone posts a patch, and if someone with approriate privileges wants to approve it, do so, or else reject it, and the losers go off and steam over this until lunch. If you still hold a grudge next year, you can find someone to burn in effigy at the next GCC Summit.
Re: backslash whitespace newline
Daniel Berlin wrote: Which is invariably why it has generated so much discussion. Surely everyone is familiar with Parkinson's second law (time spent discussing an issue is inversely proportional to its importance) I believe every opinion anyone could ever have about this issue has been put forth, and nobody on either side has been convinced of anything, other than that the other side just doesn't get it. Well the purpose of the discussion here is precisely to see if there is a consensus for change. I think everyone understands the issue perfectly well on each side, but the answer is clearly no, there is no consensus for changing things. At this point, i believe everyone should just shut up (since nobody is offering anything new *at all*), someone posts a patch, and if someone with approriate privileges wants to approve it, do so, or else reject it, and the losers go off and steam over this until lunch. Well the thread is clear enough, with the exception of the odd subject line you just introduced (it really is better not to do this), so it is easy enough for anyone to suppress the thread if they want to If you still hold a grudge next year, you can find someone to burn in effigy at the next GCC Summit.
Re: backslash whitespace newline
Bernd Jendrissek wrote: Also, if a sed script that modifies comments is too great a burden to bear for such a beaurocracy, then using a different compiler should be even more of a red-tape jungle. If it isn't, the management system is broken and you might as well not bother with all those burdensome processes anymore - they're not doing you any good. Much as I agree with your sentiments, in many environments, the use of ISO 9000 is *required*, as in you don't get the contract if you don't follow ISO 9000. I have not seen any evidence, personally, that ISO 9000 actually ensures a perfect product, but it is a political requirement of many environments. I'm not familiar-enough with ISO 9000 to judge whether a sed script is "too great a burden", but I once worked in an environment where writing a Python script to clean some ugly code got someone (not me) fired for using an "unauthorized tool", even when the script produced a clear benefit for the project. I did not stay at that workplace very long. Is anyone using GCC in an ISO 9000 environment? Just curious. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com
Re: backslash whitespace newline
Scott Robert Ladd wrote: I'm not familiar-enough with ISO 9000 to judge whether a sed script is "too great a burden", but I once worked in an environment where writing a Python script to clean some ugly code got someone (not me) fired for using an "unauthorized tool", even when the script produced a clear benefit for the project. I did not stay at that workplace very long. It sounds like you are not familiar with ISO 9000 at all :-) This standard is about following your internal rules, it is not a set of rules itself, so if you have a rule which prohibits SED scripts in your environment, this is a rule you have created for yourself, and you cannot blame ISO 9000! One of the risks in ISO 9000 environments is being stuck with silly rules. You can get certification pretty much regardless of whether your rules make sense, just as long as you can show you follow them rigorously :-) Is anyone using GCC in an ISO 9000 environment? Just curious.
Re: backslash whitespace newline
Scott Robert Ladd wrote: Much as I agree with your sentiments, in many environments, the use of ISO 9000 is *required*, as in you don't get the contract if you don't follow ISO 9000. Actually this is not so common, we have very rarely run into this requirment. CMM model level is a much more common requirement, at least in the US. Probably other countries are different, In India and Thailand, everyone advertises ISO 9000 compliance. When you step out of customs at the Bangkok airport, you see a big booth saying "ISO 9000 compliant taxi service" :-)
Re: backslash whitespace newline
Much as I agree with your sentiments, in many environments, the use of ISO 9000 is *required*, as in you don't get the contract if you don't follow ISO 9000. I have not seen any evidence, personally, that ISO 9000 actually ensures a perfect product, but it is a political requirement of many environments. Sure, there's no question that much of ISO 9000 is useless, but I also don't see the relevance here. As I understand it, ISO 9000 talks about documentation of process, not process itself. No matter how kludgy a script might be, if it's properly documented in the procedures, there's no problem using it, at least as I understand it.
Re: backslash whitespace newline
> > I believe every opinion anyone could ever have about this issue has been > > put forth, and nobody on either side has been convinced of anything, > > other than that the other side just doesn't get it. > > Well the purpose of the discussion here is precisely to see > if there is a consensus for change. I think everyone understands > the issue perfectly well on each side, but the answer is clearly > no, there is no consensus for changing things. I'm sorry, did it require 200 emails for people to figure this out? I'd think that we could have stopped at 10, maybe less. Instead, everybody just has to throw their opinion on whitespace in, without bothering to notice someone put forth that opinion 5 minutes ago. > Well the thread is clear enough, with the exception of the > odd subject line you just introduced (it really is better > not to do this), so it is easy enough for anyone to suppress > the thread if they want to Sorry, that's the absolute wrong answer. This mailing list is supposed to be for useful technical discussion. When it was clear there was no consensus, and no patch had been produced, the thread just turned into bickering between the participants. The fact that we have to kill-file threads on a regular basis because people keep going *long after it is clear there is no technical consensus, and no patch has been posted* is a bad thing, not something we should encourage and just say "oh, kill file it". There is a line somewhere where it's clear to everyone involved no consensus has been reached, and it's not at the 200 message mark in this thread. --Dan
dw_at_high_pc = 0
Hi I have following problem When I compile c source file with options: mips64-linux-gnu-gcc -c -mabi=64 -march=rm9000 -gdwarf-2 and then when I use dwarfdump the value of atribute dw_at_high_pc is 0 that is surely wrong value could you help me please to solve this problem (if I have to use some additional option when compiling or what I need to do that I would have produced correct debug information) Thank you very much and have a nice day __ http://www.inzeraty.sk/ - Bezplatná inzercia v najobľúbenejších kategóriách
Re: dw_at_high_pc = 0
On Thu, 2005-10-27 at 16:06 +0200, Ladislav Lestan wrote: > Hi > I have following problem > When I compile c source file with options: > > mips64-linux-gnu-gcc -c -mabi=64 -march=rm9000 -gdwarf-2 > > and then when I use dwarfdump the value of atribute dw_at_high_pc is 0 that > is surely wrong value > > could you help me please to solve this problem (if I have to use some > additional option when compiling or what I need to do that I would have > produced correct debug information) > > Thank you very much and have a nice day > > You are looking at the unrelocated value, since you have compiled an object file. If you link the result, and look again, it should have the correct high_pc.
Re: backslash whitespace newline
Robert Dewar wrote: It sounds like you are not familiar with ISO 9000 at all :-) This standard is about following your internal rules, it is not a set of rules itself, so if you have a rule which prohibits SED scripts in your environment, this is a rule you have created for yourself, and you cannot blame ISO 9000! One of the risks in ISO 9000 environments is being stuck with silly rules. You can get certification pretty much regardless of whether your rules make sense, just as long as you can show you follow them rigorously :-) Ah! I worked in only one place, a defense contractor, where ISO 9000 was "followed", and the way management talked, their procedures were dictated by ISO 9000. So I gather my one experience gave me an inaccurate view of the subject? So I assume it is possible for an ISO 9000 environment to allow for ad hoc sed scripts to fix trivial problems, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com
Re: backslash whitespace newline
So I assume it is possible for an ISO 9000 environment to allow for ad hoc sed scripts to fix trivial problems, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? The question is what does "ad hoc" mean? Certainly, you can have any such script as part of a procedure as long as it's specified as part of the description of that procedure. Putting some generic statement such as "ad hoc scripts are allowed at any time whenever useful" likely wouldn't do.
Re: backslash whitespace newline
> So I assume it is possible for an ISO 9000 environment to allow for > ad hoc sed scripts to fix trivial problems, and it would be the > specific institution, and not ISO 9000, that is broken (IMHO) if > any rule prevented such utilitarian acts? When one of my previous employers went ISO9000, it (iso) was described as a way of guaranteeing that the company produced the exact same faulty concrete life preservers every single time (no, we didn't make life preservers). ISO 9000 doesn't stop you from making changes. It just stops you from making *undocumented* changes. By definition, there are no ad hoc *anythings* - if you need to add a sed script, you need to document that a sed script is to be used at that point.
Re: backslash whitespace newline
Scott Robert Ladd wrote: Ah! I worked in only one place, a defense contractor, where ISO 9000 was "followed", and the way management talked, their procedures were dictated by ISO 9000. So I gather my one experience gave me an inaccurate view of the subject? The only sense in which the procedures were dictated was that ISO 9000 says you must follow your own procedures, but these procedures you were following were made up by the contractor, not by ISO 9000. So I assume it is possible for an ISO 9000 environment to allow for ad hoc sed scripts to fix trivial problems, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? Exactly
Re: backslash whitespace newline
Daniel Berlin wrote: I'm sorry, did it require 200 emails for people to figure this out? I'd think that we could have stopped at 10, maybe less. Instead, everybody just has to throw their opinion on whitespace in, without bothering to notice someone put forth that opinion 5 minutes ago. Not only is it one of those threads that requires hundreds of technical messages, but apparently it is also one of these threads which will now be further polluted by anguished cries to stop posting more junk messages to the thread, no doubt complete with discussion of whether such entreaties are appropriate :-)
Re: backslash whitespace newline
On Oct 27, 2005, Robert Dewar <[EMAIL PROTECTED]> wrote: > When you step out of customs at the Bangkok airport, you see a big > booth saying "ISO 9000 compliant taxi service" :-) ``Sorry, sir, can't drive you $there, my procedure says I can only take passengers $elsewhere. I'm afraid the driver whose procedure is to take people $there is on leave today.'' :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
GccPowerpc eabi HowTo - probem with stido functions ( sprintf)
Hello Please your's advice.I think such a problem with newlib...or with my gcc powerpc building process or with the makefile I attach a Zip example. Please your remarks to the following procedure A. Under Cygwin - XP SP2 machine Getting the following tar files than extract / cerate the following subdirectories under C:\ cygwin\gnu_src\ < binutils-2.16.1> Pease your remarks to the building procedure 1. binutils-2.16.1- ftp://mirror.switch.ch/mirror/gnu/binutils/ extract / create subdirectory C:\ cygwin\gnu_src\binutils-2.16.1 $./configure --target=powerpc ?eabi # maks # make install 2. gcc-4.0.2 - ftp://mirror.switch.ch/mirror/gnu/gcc/ extract / create subdirectory Create a spraete directory GccPowerpc create subdirectory C:\ cygwin\gnu_src\GccPowerpc - $../gcc ?4.0.2/configure --target=powerpc-eabi ?-enable ?languages=?c? # maks # make install 3.gdb-6.3. - ftp://mirror.switch.ch/mirror/gnu/gdb/extract / create subdirectory C:\ cygwin\gnu_src\gdb-6.3- $./configure --target=powerpc ?eabi # maks # make install 4.newlib-1.13.0 . - http://sourceware.org/newlib/ extract / create subdirectory C:\ cygwin\gnu_src\gdb-6.3- $./configure --target=powerpc ?eabi # maks # make install I build a sample IDE - Eclipse - which demonstrated the problem only a main which contain sprintf command.see attach The following example caused to a following linker problem char buff[20]; sprintf (buff, "%s%d", "my_test",100); / usr/local/bin/../powerpc-eabi/lib/libc.a(vfprintf.o)(.text+0x18a0): In function `_vfprintf_r': ../../../.././newlib/libc/stdio/vfprintf.c:1065: undefined reference to `__umoddi3' /usr/local/bin/../powerpc-eabi/lib/libc.a(vfprintf.o)(.text+0x18bc):../../../.././newlib/libc/stdio/vfprintf.c:1066: undefined reference to `__udivdi3' /usr/local/bin/../powerpc-eabi/lib/libc.a(makebuf.o)(.text+0x12c): In function `__smakebuf': ../../../.././newlib/libc/stdio/makebuf.c:96: undefined reference to `isatty' /usr/local/bin/../powerpc-eabi/lib/libc.a(sbrkr.o)(.text+0x40): In function `_sbrk_r': ../../../.././newlib/libc/reent/sbrkr.c:60: undefined reference to `sbrk' /usr/local/bin/../powerpc-eabi/lib/libc.a(writer.o)(.text+0x48): In function `_write_r': ../../../.././newlib/libc/reent/writer.c:58: undefined reference to `write' /usr/local/bin/../powerpc-eabi/lib/libc.a(closer.o)(.text+0x40): In function `_close_r': ../../../.././newlib/libc/reent/closer.c:53: undefined reference to `close' /usr/local/bin/../powerpc-eabi/lib/libc.a(fstatr.o)(.text+0x44): In function `_fstat_r': ../../../.././newlib/libc/reent/fstatr.c:62: undefined reference to `fstat' /usr/local/bin/../powerpc-eabi/lib/libc.a(lseekr.o)(.text+0x48): In function `_lseek_r': ../../../.././newlib/libc/reent/lseekr.c:58: undefined reference to `lseek' /usr/local/bin/../powerpc-eabi/lib/libc.a(readr.o)(.text+0x48): In function `_read_r': ../../../.././newlib/libc/reent/readr.c:58: undefined reference to `read' make: *** [ADLAP.elf] Error 1 Only this example working well only without %d ? It?s insignificant for me sprintf (buff, "%s", "my_test"); powerpc-eabi-ld -Map ADLAP.map -o ADLAP.elf appl.o main.o hardware.o init.o -T lnk_mpc555_rom.lcf -L c:/555/libumas -lumas -lm -lc powerpc-eabi-objcopy -O srec ADLAP.elf ADLAP.rom powerpc-eabi-objdump -Sx ADLAP.elf > ADLAP.dump what can be the problam ? This simple build project which generate the same errors as our operational project I'll appreciated if u can take a look on the Zip attachment open it, and see what can be wrong (TestEnvironment.zip) Maybe I miss something following the building the GCC for powerpc -Regarding to GCC-Powerpc Looking forwarded to your response asap. Moshe Drori -- Sent from the gcc - General forum at Nabble.com: http://www.nabble.com/GccPowerpc-eabi-HowTo---probem-with-stido-functions-%28-sprintf%29-t457952.html#a1250042
Re: backslash whitespace newline
Daniel Berlin wrote: I believe every opinion anyone could ever have about this issue has been put forth, and nobody on either side has been convinced of anything, other than that the other side just doesn't get it. Well the purpose of the discussion here is precisely to see if there is a consensus for change. I think everyone understands the issue perfectly well on each side, but the answer is clearly no, there is no consensus for changing things. I'm sorry, did it require 200 emails for people to figure this out? I'd think that we could have stopped at 10, maybe less. Ah, to be young again and always know the correct answer right away. :-) But these kinds of issues do get tough when one looks outside the echo chamber of GCC compiling itself. This mailing list is supposed to be for useful technical discussion. When it was clear there was no consensus, and no patch had been produced, the thread just turned into bickering between the participants. What, did you get a connection to "the intarnets" 15 minutes ago? This has been my experience with technical mailing lists since I first got on the net 23 years ago. The daring might even venture to say it's... human nature. (Yes yes, I know there are subscribers whose human status is doubtful, but I'm feeling generous today. :-) ) Stan
Re: [Steven Woody] M16C development using GCC, Is It Possible?
DJ Delorie <[EMAIL PROTECTED]> writes: >> i heard that gcc is also a cross-compiler, so i want to get know if >> it can be used as an M16C compiler? > > Yes. The target you want to use to build gcc et al is "m32c-elf". > > To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..." thanks. is that a 4.02 option? i can not find them on my 3.4 gcc man page. > >> in GCC's home page, there is one item: >> >> 'July 20, 2005 >> Red Hat Inc has contributed a port for the Renesas R8C/M16C/M32C >> families' >> >> what that really means? > > It means that Red Hat Inc has modified gcc (and binutils and newlib) > to support the r8c/m16c/m32c family of processors from Renesas, and > given those changes to the FSF to be integrated into their official > sources. how it going on? have it been alreay available in 4.02? > > gdb and a simulator are still in progress. that seem ok since i currently only need gcc. and, because i am new to the field , i want to ask, what is a 'simulator'? run target excutable on host computer? >> and in this page >> 'http://a15177702.alturo-server.de/gcc-m16c/20050419.html', it said, GCC >> M16C project is totally bugy. > > That's a different attempt to port gcc to m16c, and has nothing to do > with what I did. sorry, are you the author of the new m16c/gcc code? i noticed your domain name is redhat. > >> (BTW: i need compile C++ not C only) > > Note that I haven't gotten around to supporting C++ yet. You can try > to build it if you want, but I had deferred it due to other more > important issues, and haven't had a chance to work on it. It might > "just work", you never know ;-) do you mean, the current m16c/gcc code never compiler c++ code? if so, that is definitely a bad news to me, since our project based on EC++ (Embedded C++). though you pointed that i could build for my self, but in fact i can not, i know nothing about compiler writing :( so, i am thinking another question. if i can write the code which can pass both the current (3.4) g++ compiler and the IAR M16C C++ compiler, so my problem will resolved. but is it possible of the idea? i think i can use some #ifdef statements and move any IO into stubs. how different are these two compilers in C++ syntax? i like to heard any suggestion, and thank you in advance. -- steven woody (id: narke) Pepper...is hot and scorches, just like the sun - Politiki kouzina (2003)
Re: [Steven Woody] M16C development using GCC, Is It Possible?
> > To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..." > > thanks. is that a 4.02 option? i can not find them on my 3.4 gcc man page. The r8c/m16c/m32c port is new. Currently, it's only in the mainline CVS sources, and will be "officially" released in the gcc 4.1 series. > > gdb and a simulator are still in progress. > > that seem ok since i currently only need gcc. You'll need binutils also, at least, and probably newlib to get crt0 and some sample libraries and linker scripts. > and, because i am new to the field , i want to ask, what is a > 'simulator'? run target excutable on host computer? Yes. > > That's a different attempt to port gcc to m16c, and has nothing to do > > with what I did. > > sorry, are you the author of the new m16c/gcc code? i noticed your > domain name is redhat. I am one of the authors, and the current maintainer. > do you mean, the current m16c/gcc code never compiler c++ code? No, it just means I haven't tried it recently. It mostly worked back when I was working in that area, but "mostly" wasn't good enough for what I was doing, so I just skipped it, as I didn't need C++ back then. > C++). though you pointed that i could build for my self, but in fact > i can not, i know nothing about compiler writing :( Compiler building, not compiler writing. I already did the writing part. > so, i am thinking another question. if i can write the code which > can pass both the current (3.4) g++ compiler and the IAR M16C C++ > compiler, so my problem will resolved. but is it possible of the > idea? i think i can use some #ifdef statements and move any IO into > stubs. how different are these two compilers in C++ syntax? The pragmas for assigning addresses to I/O variables are different, but it's only a header change to get them working with gcc. Note that g++'s C++ is much more strict and current than most other C++ compilers; it's likely you'll have to fix your code to get it to work, but this would be due to code bugs and not g++ bugs if so.
Excess precision problem on IA-64
Hi,
We have run into an excess precision problem on IA-64, similar to the infamous
problem on IA-32. A C testcase is attached.
[EMAIL PROTECTED]:~/EA26-004> gcc -v
Using built-in specs.
Target: ia64-sgi-linux-gnu
Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu
--prefix=/nile.build/botcazou/fsf/install_ia64 --disable-nls
--disable-libmudflap --disable-checking --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0 20051024 (experimental)
[EMAIL PROTECTED]:~/EA26-004> gcc -o t t.c
[EMAIL PROTECTED]:~/EA26-004> ./t
[EMAIL PROTECTED]:~/EA26-004> gcc -o t t.c -O
[EMAIL PROTECTED]:~/EA26-004> ./t
Aborted
The bottom line is that:
fmpy.s f8 = f8, f15
fma.s f8 = f11, f12, f8
doesn't always give 0.0 in f8 when f8 = f15 = f11 = -f12, because the
computations are done in "infinite precision" and only rounded at the end.
What should we do about that? Conditionalize the combined FP operations on
-ffast-math or something along these lines?
Thanks in advance.
--
Eric Botcazou
extern void abort (void);
typedef struct
{
float X;
float Y;
float Z;
float S;
} Unit_Quaternion_Type;
Unit_Quaternion_Type Mult (Unit_Quaternion_Type Left, Unit_Quaternion_Type Right)
{
Unit_Quaternion_Type ret
= {Left.S * Right.X + Left.X * Right.S + Left.Y * Right.Z - Left.Z * Right.Y,
Left.S * Right.Y - Left.X * Right.Z + Left.Y * Right.S + Left.Z * Right.X,
Left.S * Right.Z + Left.X * Right.Y - Left.Y * Right.X + Left.Z * Right.S,
Left.S * Right.S - Left.X * Right.X - Left.Y * Right.Y - Left.Z * Right.Z};
return ret;
}
int main(void)
{
Unit_Quaternion_Type A = { 0.707106769, 0.0, 0.0, 0.707106769};
Unit_Quaternion_Type B = {-0.707106769, 0.0, 0.0, 0.707106769};
Unit_Quaternion_Type C;
C = Mult (A, B);
if (C.X != 0.0)
abort ();
return 0;
}
Re: Excess precision problem on IA-64
> > --Boundary-00=_dFRYDl9RKCduOdb > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hi, > > We have run into an excess precision problem on IA-64, similar to the > infamous > problem on IA-32. A C testcase is attached. > > [EMAIL PROTECTED]:~/EA26-004> gcc -v > Using built-in specs. > Target: ia64-sgi-linux-gnu > Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu > --prefix=/nile.build/botcazou/fsf/install_ia64 --disable-nls > --disable-libmudflap --disable-checking --enable-languages=c,c++ > Thread model: posix > gcc version 4.1.0 20051024 (experimental) > [EMAIL PROTECTED]:~/EA26-004> gcc -o t t.c > [EMAIL PROTECTED]:~/EA26-004> ./t > [EMAIL PROTECTED]:~/EA26-004> gcc -o t t.c -O > [EMAIL PROTECTED]:~/EA26-004> ./t > Aborted > > The bottom line is that: > > fmpy.s f8 = f8, f15 > fma.s f8 = f11, f12, f8 > > doesn't always give 0.0 in f8 when f8 = f15 = f11 = -f12, because the > computations are done in "infinite precision" and only rounded at the end. > > > What should we do about that? Conditionalize the combined FP operations on > -ffast-math or something along these lines? This seems like any other target which has a fused multiply and add instruction like PPC. Maybe a target option to turn on and off the fma instruction like there is for PPC. -- Pinski
Re: Excess precision problem on IA-64
> This seems like any other target which has a fused multiply and add > instruction like PPC. Maybe a target option to turn on and off the fma > instruction like there is for PPC. I'm under the impression that it's worse on IA-64 because of the "infinite precision", but I might be wrong. -- Eric Botcazou
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
Dorit wrote: It looks like maybe a 64bit scalar-evolution issue - when I compile on powerpc-linux with -m64, I also get the "vect4.f:4: note: not consecutive access" message. This problem looks very similar to PR18403 which has been resolved a while ago: When compiling for 32bit, we get the following representation for the loop: # i_2 = PHI ; :; D.505_38 = i_2 + -1; D.506_39 = (*b_14)[D.505_38]; (*a_9)[D.505_38] = D.506_39; i_41 = i_2 + 1; if (i_2 == D.489_27) goto ; else goto ; When compiling for 64bit, there is an extra cast: # i_2 = PHI ; :; D.691_41 = (int8) i_2; D.692_42 = D.691_41 + -1; D.693_43 = (*b_16)[D.692_42]; (*a_10)[D.692_42] = D.693_43; i_45 = i_2 + 1; if (i_2 == D.674_29) goto ; else goto ; Shouldn't the cast be hoisted out of the loop ? The cast of a loop invariant variable (i_2) is itself loop-invariant. Anyway, while we're waiting for Daniel to complete the cvs-svn transition, we can have some more fun with vectors: SUBROUTINE S(N) DIMENSION A(N), B(N) READ*,ISTART,ISTOP,B DO I = ISTART, ISTOP A(I) = B(I) ENDDO PRINT*,A END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f vect4.f:4: note: not vectorized: complicated access pattern. vect4.f:4: note: vectorized 0 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f vect4.f:4: note: LOOP VECTORIZED. vect4.f:4: note: vectorized 1 loops in function. That's what your experience with powerpc64 was too. SUBROUTINE S(N) DIMENSION A(N), B(12) COMMON /COM/ B DO I = 1, 12 A(I) = B(I) ENDDO PRINT*,A(1:12) END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f vect5.f:4: note: LOOP VECTORIZED. vect5.f:4: note: vectorized 1 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f vect5.f:4: note: LOOP VECTORIZED. vect5.f:4: note: vectorized 1 loops in function. Hmmm, this one is now also vectorised with -m64 - obviously a different problem. SUBROUTINE S(N) INTEGER N COMMON /COM/ A(100) REAL A REAL B(N), C(N), D(N) DO I = 1, N B(I) = D(I) ENDDO DO I = 1, N A(I) = B(I) ENDDO CALL S1(C(1)) END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 -ffixed-form vecta.f vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: not vectorized: can't determine dependence between (*b_16)[D.928_30] and com.a[D.928_30] vecta.f:9: note: vectorized 1 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 -ffixed-form vecta.f vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: LOOP VECTORIZED. vecta.f:9: note: vectorized 2 loops in function. But this one only works in 32 bits. I'm now going to try to compile HIRLAM with 32 bit pointers. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
resolving backslash newline whisky tango foxtrot: a proposal
Daniel was right in that the discussion has degenerated. So, here's
a concrete proposal. Think of it as a start on a documentation patch.
Since there is no consensus, it seems that the right solution is to
have options. I think that the following concept can solve the problems.
-fno-eol-whitespace-strip
If this flag is specified, then only '\\$', not '\\ *$', causes a line
to be continued. (We default to current gcc behavior, which is
-feol-whitespace-strip).
-Wcontinued-cpp-comment
Warn if there is a C++-style comment that is continued by a backslash at
the end of the line, and the following line contains something other
than whitespace and comments. The current setting of
-f{no-}eol-whitespace-strip is used to decide what is a continued
comment.
-Wcontinued-cpp-comment could be included in -Wall, or not; we could
experiment with codebases to see what gets flagged. I think it's a
good idea to put it there, though.
Apple's customer could use -fno-eol-whitespace-strip, and the warning
would flag any line art that loses its trailing space (for cases where
it matters). The warning, if implemented correctly, will be silent
except for surprises where text gets commented out unexpectedly.
An additional possiblity would be
-fno-cpp-continued-comments
This flag causes the compiler to diverge from the ISO C and C++
standards! If it is specified, then a trailing backslash in a C++-style
comment is simply ignored.
Re: resolving backslash newline whisky tango foxtrot: a proposal
> -Wcontinued-cpp-comment
>
> Warn if there is a C++-style comment that is continued by a backslash at
> the end of the line, and the following line contains something other
> than whitespace and comments. The current setting of
> -f{no-}eol-whitespace-strip is used to decide what is a continued
> comment.
We already have this included in -Wall via -Wcomment.
-- Pinski
Re: resolving backslash newline whisky tango foxtrot: a proposal
I'm good with this proposal. I was against the flag in the first place for a desire to pick something and let's do that, but it seems like with so much furor over it we should probably just have a flag. :) -eric
Re: Excess precision problem on IA-64
On Oct 27, 2005, at 14:12, Eric Botcazou wrote: I'm under the impression that it's worse on IA-64 because of the "infinite precision", but I might be wrong. Fused multiply-add always uses "infinite precision" in the intermediate result. Only a single rounding is performed at the end. We really should have a way to express situations where operations may or may not be contracted, instead of having to do this on a whole-compilation level. Many computations, especially those involving higher-precision intermediate results, are far easier to implement with explicit control over cases where contractions are allowed. Such techniques are used a lot for implementation of correctly rounded elementary functions. Currently the only way we can get that kind of precision, while being able to have the code inlined, is to use assembler insertions, that unnecessarily make the code system dependent. -Geert
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
I wrote: I'm now going to try to compile HIRLAM with 32 bit pointers. And ... here are the results: With 64-bit pointers: 2685 out of 9799 loops vectorized. With 32-bit pointers: 3269 out of 8854 loops vectorized. Why there are more loops in the 64-bit case is beyond my understanding - it's the same code base as I worked on with the 32-bit compilation ... Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Excess precision problem on IA-64
> Fused multiply-add always uses "infinite precision" in the intermediate > result. Only a single rounding is performed at the end. Of course, but I was implicitly referring to the 82-bit thing. But it seems I was wrong, as the testcase fails on PowerPC w/ -mfused-madd too. -- Eric Botcazou
Re: backslash whitespace newline
So I assume it is possible for an ISO 9000 environment to allow for ad hoc sed scripts to fix trivial problems, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? ISO9000 is a pretty broad word these days. As someone amusingly pointed out, you can ride in an ISO9000 taxi. When I raised the point about not using a sed script to change code becuase of implications in an ISO9000 environment, I was talking about a slightly more "normal" usage of the term "ISO9000". It is common, in military and government work, especially when the contracts span multiple governments, that you have to be "ISO9000 compliant". Yes, the standards body in whatever country you work have to verify that you do have coding practices and procedures defined and that you do adhere to them, but thats not the important audit. Certainly in the environment in which I worked, it was the project itself that audited the procedures to make sure they were sane. So the standards body tests your adherance to the procedures, but the client tests the quality of the procedures themselves. I have limited exposure to ISO9000 environments but the one in which I did work, where the software was responsible for maintaining billions and billions of dollars of equipment across multiple government boundaries, those procedures were anal in the extreme. Every single line of code had been audited, both internally and by two independent auditors. The procedures we had to follow to make even a single line change in parts of the system ran into months. In such an environment, "just use a sed script" is a totally unacceptable solution. It was actually *easier* for us to move from Sunpro cc to gcc than it was to make changes to certain parts of the system. Part of the reason is that compilers were frequently "certified" for a much broader range of products, so once it was on the customer's "approved" list, we were free to change compilers. Of course, we didn't have code that had funky newline problems :) Kean
Re: GccPowerpc eabi HowTo - probem with stido functions ( sprintf)
moshed (sent by Nabble.com) wrote: / usr/local/bin/../powerpc-eabi/lib/libc.a(vfprintf.o)(.text+0x18a0): In function `_vfprintf_r': .../../../.././newlib/libc/stdio/vfprintf.c:1065: undefined reference to `__umoddi3' These are in the libgcc library. /usr/local/bin/../powerpc-eabi/lib/libc.a(vfprintf.o)(.text+0x18bc):../../../.././newlib/libc/stdio/vfprintf.c:1066: undefined reference to `__udivdi3' /usr/local/bin/../powerpc-eabi/lib/libc.a(makebuf.o)(.text+0x12c): In function `__smakebuf': .../../../.././newlib/libc/stdio/makebuf.c:96: undefined reference to `isatty' These are syscalls, which need to be provided by you. There are stubs you can use in libgloss. Only this example working well only without %d ? It?s insignificant for me sprintf (buff, "%s", "my_test"); If you compile with optimization, gcc will convert this to a string copy which needs no library calls. powerpc-eabi-ld -Map ADLAP.map -o ADLAP.elf appl.o main.o hardware.o init.o -T lnk_mpc555_rom.lcf -L c:/555/libumas -lumas -lm -lc Using ld to link is almost always a mistake. You should use gcc to link instead, and this will solve half your trouble, which is the failure to link in libgcc. If you really need to use ld directly, then use gcc -v to see what the correct linker command is, and then modify as necessary. The other half is probably a bug in your linker script, not including the necessary libgloss system call stubs which will work on the simulator. If you are running on a bare board, then you will need syscall stubs that call monitor routines. Some of these may not be supported on the board, in which case you can return an error, and just avoid calling them. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Exception propagation problem on IA-64/Linux
Hi,
We have run into an exception propagation problem on IA-64/Linux. An
admittedly contrived C++ testcase is attached.
[EMAIL PROTECTED]:~/EA27-007> g++ -v
Using built-in specs.
Target: ia64-sgi-linux-gnu
Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu
--prefix=/nile.build/botcazou/fsf/install_ia64 --disable-nls
--disable-libmudflap --disable-checking --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0 20051024 (experimental)
[EMAIL PROTECTED]:~/EA27-007> g++ -o t t.C u.C
[EMAIL PROTECTED]:~/EA27-007> ./t
[EMAIL PROTECTED]:~/EA27-007> g++ -o t u.C t.C
[EMAIL PROTECTED]:~/EA27-007> ./t
struct S exception caught!
The problem pertains to the type_info objects emitted for the exceptions:
while the exceptions in t.C and u.C are unrelated, these objects are the
same. On IA-32 they are local to the translation unit, but on IA-64 they are
DECL_ONE_ONLY because of dw2_force_const_mem.
Now we have in dw2_asm_output_encoded_addr_rtx:
/* Indirection is used to get dynamic relocations out of a
read-only section. */
if (encoding & DW_EH_PE_indirect)
{
/* It is very tempting to use force_const_mem so that we share data
with the normal constant pool. However, we've already emitted
the constant pool for this function. Moreover, we'd like to
share these constants across the entire unit of translation,
or better, across the entire application (or DSO). */
addr = dw2_force_const_mem (addr);
encoding &= ~DW_EH_PE_indirect;
goto restart;
}
It seems to me that it's not the job of dw2_force_const_mem to do the sharing
"across the entire application (or DSO)", but that of the linker. Its head
comment still reads:
/* Put X, a SYMBOL_REF, in memory. Return a SYMBOL_REF to the allocated
memory. Differs from force_const_mem in that a single pool is used for
the entire unit of translation, and the memory is not guaranteed to be
"near" the function in any interesting sense. */
The "across the entire application (or DSO)" thing was added afterwards:
2001-11-08 Jakub Jelinek <[EMAIL PROTECTED]>
* dwarf2asm.c (mark_indirect_pool_entry, mark_indirect_pool): New.
(USE_LINKONCE_INDIRECT): Define.
(dw2_output_indirect_constant_1): Try to output indirect constants
into linkonce sections if possible.
(dw2_force_const_mem): Likewise. Register indirect_pool with GGC.
(dw2_output_indirect_constants): Likewise.
Thoughts?
--
Eric Botcazou
#include
extern void bar(void);
static void foo(void)
{
struct S { int i; };
try {
bar ();
}
catch (struct S) {
printf ("struct S exception caught!\n");
}
catch (...) {}
}
int main(void)
{
foo ();
return 0;
}
bool pred = false;
static void foo(void)
{
struct S { double d; } s1;
if (pred) {
try { foo(); }
catch (struct S) { foo(); }
}
throw s1;
}
void bar(void)
{
foo ();
}
Error in "SSH connection caching" entry
It says it is *recommended* that $HOME/.ssh/config have permission 600. However, I seem to get an error if it doesn't, so I think this should be "required", not "recommended".
Re: Error in "SSH connection caching" entry
On Thursday 27 October 2005 21:22, Richard Kenner wrote: > It says it is *recommended* that $HOME/.ssh/config have permission 600. > However, I seem to get an error if it doesn't, so I think this should be > "required", not "recommended". There's also a reason why it's a wiki. Paul
Re: Exception propagation problem on IA-64/Linux
On Thu, Oct 27, 2005 at 10:21:08PM +0200, Eric Botcazou wrote: > We have run into an exception propagation problem on IA-64/Linux. An > admittedly contrived C++ testcase is attached. I'm not sure that the C++ testcase is in fact valid. A lawyer would have to actually weigh in on that claim. > The problem pertains to the type_info objects emitted for the exceptions: > while the exceptions in t.C and u.C are unrelated, these objects are the > same. On IA-32 they are local to the translation unit, but on IA-64 they are > DECL_ONE_ONLY because of dw2_force_const_mem. Try again on ia32 with -fpic. That should go through dw2_force_const_mem just the same. > Thoughts? I don't think this is an EH problem at all. I think the test case is either invalid, or that the bug is in the C++ front end in how we mangle (or not) the local class. r~
Re: resolving backslash newline whisky tango foxtrot: a proposal
> > -Wcontinued-cpp-comment
> >
> > Warn if there is a C++-style comment that is continued by a backslash at
> > the end of the line, and the following line contains something other
> > than whitespace and comments. The current setting of
> > -f{no-}eol-whitespace-strip is used to decide what is a continued
> > comment.
On Thu, Oct 27, 2005 at 02:35:38PM -0400, Andrew Pinski wrote:
> We already have this included in -Wall via -Wcomment.
No, we don't. Consider
--
// this is a continued comment \
// but who cares, because this is a comment too
int i = 1;
--
% gcc -Wall -c foo.C
foo.C:1:1: warning: multi-line comment
Under the description I provided, there would be no warning, because
the continued comment does not change which text is commented out.
The "line art" people aren't going to find this acceptable.
Perhaps the thing to do is to fix -Wcomment to eliminate the noise,
so it will be more useful; then we don't need a new -W option.
So the amended suggestion is to fix -Wcomment to shut up about continued
comments that don't matter, and also to add the new -f option to switch
the handling of spaces-at-the-end.
Re: What is really a new line in most compilers
On Oct 27, 2005, at 12:06 AM, Paolo Bonzini wrote: Unfortunately, GUI programs such as TextEdit seem not to know this, Odd, I just created a file and saved it: mrs $ od -c -x ~/Desktop/barfoo.c 000m i k e \n w a s \n h e r e \n 6d696b650a7761730a686572650a (on 10.4.2)
Re: Exception propagation problem on IA-64/Linux
> I'm not sure that the C++ testcase is in fact valid. A lawyer would > have to actually weigh in on that claim. OK. But we have valid Ada testcases exhibiting the problem. > Try again on ia32 with -fpic. That should go through > dw2_force_const_mem just the same. Right, but the problem doesn't trigger, probably because of the relative encoding: .LLSDACSE3: .byte 0x1 .byte 0x0 .align 4 .long DW.ref._ZTIZ3foovE1S-. > I don't think this is an EH problem at all. I think the test case > is either invalid, or that the bug is in the C++ front end in how we > mangle (or not) the local class. Yes, I think that's the crux of the matter: for the time being, neither the C++ nor the Ada front-end mangles local exceptions. Either they should or the problem lies in the EH machinery. -- Eric Botcazou
Re: Excess precision problem on IA-64
Geert Bosch <[EMAIL PROTECTED]> writes: > On Oct 27, 2005, at 14:12, Eric Botcazou wrote: >> I'm under the impression that it's worse on IA-64 because of the >> "infinite >> precision", but I might be wrong. > > Fused multiply-add always uses "infinite precision" in the intermediate > result. Only a single rounding is performed at the end. We really should > have a way to express situations where operations may or may not be > contracted, instead of having to do this on a whole-compilation level. I think this is what the FP_CONTRACT pragma is supposed to provide. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Excess precision problem on IA-64
> > This seems like any other target which has a fused multiply and add > > instruction like PPC. Maybe a target option to turn on and off the fma > > instruction like there is for PPC. > > I'm under the impression that it's worse on IA-64 because of the "infinite > precision", but I might be wrong. > > -- > Eric Botcazou The HP compiler generates fused multiply and add by default and has several settings for the +Ofltacc option to control this (and other optimizations that affect floating point accuracy). +Ofltacc=default Allows contractions, such as fused multiply-add (FMA), but disallows any other floating point optimization that can result in numerical differences. +Ofltacc=limited Like default, but also allows floating point optimizations which may affect the generation and propagation of infinities, NaNs, and the sign of zero. +Ofltacc=relaxed In addition to the optimizations allowed by limited, permits optimizations, such as reordering of expressions, even if parenthesized, that may affect rounding error. This is the same as +Onofltacc. +Ofltacc=strict Disallows any floating point optimization that can result in numerical differences. This is the same as +Ofltacc. It would be easy enough to add an option that turned off the use of the fused multiply and add in GCC but I would hate to see its use turned off by default. Steve Ellcey [EMAIL PROTECTED]
couldn't wait with that till 1st of April...
http://www.thedailywtf.com/forums/48364/ShowPost.aspx I wonder if one day, gcc will be able to use -Ostupidity to simplify such thingies ;) For those who did not noticed yet, I am just trying to take the piss here. Thanks ;) -- Vercetti
Re: Excess precision problem on IA-64
> The HP compiler generates fused multiply and add by default and has several > settings for the +Ofltacc option to control this (and other optimizations > that affect floating point accuracy). > > +Ofltacc=default > > Allows contractions, such as fused multiply-add (FMA), but > disallows any other floating point optimization that can result > in numerical differences. > > +Ofltacc=limited > > Like default, but also allows floating point optimizations which > may affect the generation and propagation of infinities, NaNs, > and the sign of zero. > > +Ofltacc=relaxed > > In addition to the optimizations allowed by limited, permits > optimizations, such as reordering of expressions, even if > parenthesized, that may affect rounding error. This is the same > as +Onofltacc. > > +Ofltacc=strict > > Disallows any floating point optimization that can result in > numerical differences. This is the same as +Ofltacc. Thanks for the info. > It would be easy enough to add an option that turned off the use of the > fused multiply and add in GCC but I would hate to see its use turned off > by default. If that's the consensus among IA-64 maintainers, it's fine with me. -- Eric Botcazou
anonymous svn over http?
Is there a plan to support anonymous svn access via http? The possibility was mentioned in http://gcc.gnu.org/ml/gcc/2005-02/msg00618.html The svn: protocol won't work through our corporate firewall.
Re: Exception propagation problem on IA-64/Linux
On Thu, Oct 27, 2005 at 11:10:10PM +0200, Eric Botcazou wrote: > > Try again on ia32 with -fpic. That should go through > > dw2_force_const_mem just the same. > > Right, but the problem doesn't trigger, probably because of the relative > encoding: > > .LLSDACSE3: > .byte 0x1 > .byte 0x0 > .align 4 > .long DW.ref._ZTIZ3foovE1S-. What's that got to do with anything? Either we reference the same type_info in both functions or we don't. The name here would seem to imply that we *are* mangling the type name: "typeinfo for foo()::S". Which begs the question of why you're seeing something different for ia64. r~
SVN: question on checkout?
http://gcc.gnu.org/wiki/SvnSetup has the following example for checking out the GCC sources under "Checking out a tree" svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk but this doesn't work for me. Rather, I'm getting: % svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk Permission denied (publickey,gssapi-with-mic). svn: Connection closed unexpectedly Should this just read svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk -or- svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk instead? Gerald
Aliases crossing procedures
Hi, I am trying to understand alias analysis. And currently using gcc 4.0 I find that it reports a pointer crossing procedure boundaries as pointing to anything even in the simplest case of a passsing by reference. I guess interproceural analysis is hard in general but is it so even in these cases. Arent special cases possible in these scenarios'. Or is it that catering to such cases makes it lose the generality ? thanks Shrey
SVN: question on checkout?
> http://gcc.gnu.org/wiki/SvnSetup has the following example for > checking out the GCC sources under "Checking out a tree" > > svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk > > but this doesn't work for me. Rather, I'm getting: > > % svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk > Permission denied (publickey,gssapi-with-mic). > svn: Connection closed unexpectedly > > Should this just read > svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk > -or- > svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > instead? Since I added that info originally, I fixed the section on using [EMAIL PROTECTED] to make this clearer. Basically, you use it the same way you would use ssh: give the username if it's different on the remote system, don't bother otherwise. - Tobi
Re: resolving backslash newline whisky tango foxtrot: a proposal
Joe Buck <[EMAIL PROTECTED]> writes:
| > > -Wcontinued-cpp-comment
| > >
| > > Warn if there is a C++-style comment that is continued by a backslash at
| > > the end of the line, and the following line contains something other
| > > than whitespace and comments. The current setting of
| > > -f{no-}eol-whitespace-strip is used to decide what is a continued
| > > comment.
|
| On Thu, Oct 27, 2005 at 02:35:38PM -0400, Andrew Pinski wrote:
| > We already have this included in -Wall via -Wcomment.
|
| No, we don't. Consider
|
| --
| // this is a continued comment \
| // but who cares, because this is a comment too
| int i = 1;
| --
|
| % gcc -Wall -c foo.C
| foo.C:1:1: warning: multi-line comment
That one is particular annoying (in its current form). I have codes
with such backslashes coming from diagrams embedded in comments
and GCC insist in telling me that I have a multi-line comment. Now, I
have to tell students that they need to say -Wall followed by bunch of
-Wno-xxx because GCC is being overly helping with no much effort of
"understanding".
| Under the description I provided, there would be no warning, because
| the continued comment does not change which text is commented out.
| The "line art" people aren't going to find this acceptable.
I certainly do.
| Perhaps the thing to do is to fix -Wcomment to eliminate the noise,
| so it will be more useful; then we don't need a new -W option.
I strongly support that suggestion.
-- Gaby
Problem building *-rtems on the head
Or at least I think it's the head. I am still learning subversion. :)
I am testing using gcc-head-test with the *-rtems targets. I managed
to build a native compiler and am using that to build the cross
compilers. But when the build gets around to trying to build newlib, it
is using CC=${target}-cc not the xgcc from the built gcc subdirectory.
I am using the same configure command I used with gcc 4.0.x and
including --with-newlib.
Has anyone else tried to build a newlib target from the head recently?
--joel sherrill
Re: Problem building *-rtems on the head
> > > Or at least I think it's the head. I am still learning subversion. :) The SVN version of the head that is live right now is still a couple weeks old. So any troubles you have right now might just be due to that. You can try cvs which is in a read only state (for the rest of its life). > Has anyone else tried to build a newlib target from the head recently? IIRC there were some problems which had been fixed days after the problems were created. -- Pinski
Re: anonymous svn over http?
On Thu, 27 Oct 2005, Joe Buck wrote: Is there a plan to support anonymous svn access via http? It can be slower and more resource intensive. I'd like to avoid it if possible, but if not,
SSH connection caching
When I do it, it looks like after I log out, something is still running. Is there something I have to stop?
Re: question on checkout?
Tobias Schlüter <[EMAIL PROTECTED]> wrote: >> http://gcc.gnu.org/wiki/SvnSetup has the following example for >> checking out the GCC sources under "Checking out a tree" >> >> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk >> >> but this doesn't work for me. Rather, I'm getting: >> >> % svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk >> Permission denied (publickey,gssapi-with-mic). >> svn: Connection closed unexpectedly >> >> Should this just read >> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk >> -or- >> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk >> instead? > > Since I added that info originally, I fixed the section on using > [EMAIL PROTECTED] > to make this clearer. Basically, you use it the same way you would > use ssh: give the username if it's different on the remote system, > don't bother otherwise. The section is unneeded and duplicates the first paragraph of SvnBasic. Please, make sure to not insert duplicate information in the Wiki, prefer to link. I have removed the duplicate. Giovanni Bajo
Re: Excess precision problem on IA-64
On Oct 27, 2005, at 17:19, Andreas Schwab wrote: I think this is what the FP_CONTRACT pragma is supposed to provide. Yes, but it seems there is no way in the middle end / back end to express this. Or am I just hopelessly behind the times? :) -Geert
Re: New SVN Wiki page
Mike Stump <[EMAIL PROTECTED]> wrote: >> Uhm, I'm not sure how to explain this without being too pedantic. >> Does this >> sound clearer? > > This tool tracks each individual change (fine-grained) and will never > reapply an already applied change. > > I think that is a high level answer, and completely answers the > question to people that have the question, while doing as little as > possible to confuse someone that doesn't even have the question. > Anyone doing merges should have the question and understand the > answer. > > Or, you can say it merges in N-1 to N, when one requests a merge of > N. A totally different way of expressing the same thing, and conveys > the same information. > > Sound reasonable? Thanks for the suggestion, I have incorporated this into the Wiki page, I hope it's clearer now. Giovanni Bajo
Re: Properly setting the pkcconfig directory (was: Moving the pkgconfig directory from lib/ to libdata/?)
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: Gerald> This is fine to use, but our configure/build system really should Gerald> be clever enough to automatically set pkgdatadir to the correct Gerald> value in the first place: $(prefix)/libdata/pkgconfig on FreeBSD, Gerald> and $(libdir)/pkgconfig elsewhere. Are there other places where we try to auto-detect install directory names? I don't know of any. It would be simple to add something like --with-pkgdatadir to configure. It sounds like you are talking about a build for a distro; requiring a configure option for that doesn't sound like a big deal (as presumably you already need --prefix=/usr among other things). Tom
Re: Aliases crossing procedures
On Thursday 27 October 2005 18:37, shreyas krishnan wrote: > I find that it reports a pointer crossing procedure > boundaries as pointing to anything even in the simplest case of a > passsing by reference. Yes, that's one of the basic limitations in 4.0. Several of these limitations are going to be addressed in the 4.2 release. The SVN branch improved-aliasing-branch contains the bulk of the improvements planned for 4.2.
Re: Excess precision problem on IA-64
On Oct 27, 2005, at 17:25, Steve Ellcey wrote: It would be easy enough to add an option that turned off the use of the fused multiply and add in GCC but I would hate to see its use turned off by default. Code that cares should be able to express barriers across which no contraction is possible. Especially with templates or inlining across compilation units, global flags become too limited. Many useful primitives can only be implemented with exact knowledge of where rounding happens. With arbitrary contractions, numerical analysis becomes infeasible and some essential algorithms break down completely. For example, you may have code that evaluates some polynomials and other straightforward computations involving approximated inputs. This code may benefit from contractions due to fused multiply-add both with regards to speed and accuracy. However, then you might want to round computed values to integer, rounding halfway values away from zero. If the machine has no primitive, this may be implemented with truncation and addition of a special constant. But, when such addition gets combined with other operations, eliminating the rounding operation, the final result can be incorrect, causing numbers to be rounded the wrong way. There are two ways around this: for code targeted to a specific processor, use inline assembly for the code relying on precise rounding. The other is: compile all code with conservative optimizations. For GCC, we are interested in writing and compiling code that works across a wide range of targets. The two workarounds mentioned above either needlessly limit the performance (by using conservative optimization everywhere), or portability (by relying on inline assembly). -Geert
Re: Exception propagation problem on IA-64/Linux
> The name here would seem to imply that we *are* mangling the type > name: "typeinfo for foo()::S". Which begs the question of why you're > seeing something different for ia64. Both names are mangled identically (either on IA-32 or IA-64) because they are supposed to be local to the translation unit. -- Eric Botcazou
svn troubles
Hi, I don't seem to be able to access svn: # svn ls svn://gcc.gnu.org/svn/gcc [several (2-3) minutes pass, during which svn is non-interruptable] svn: Can't connect to host 'gcc.gnu.org': Connection timed out Ralf
Re: Exception propagation problem on IA-64/Linux
Eric Botcazou wrote: >>The name here would seem to imply that we *are* mangling the type >>name: "typeinfo for foo()::S". Which begs the question of why you're >>seeing something different for ia64. > > > Both names are mangled identically (either on IA-32 or IA-64) because they > are > supposed to be local to the translation unit. Correct. This test case is valid, and the results observed are in incorrect; in other words, yes, there is a bug. In general, comparison of type_info objects is supposed to be done by checking for address equality of the type info strings. On systems without weak symbols, we use strcmp. (Look for __GXX_MERGED_TYPEINFO_NAMES in .) In the situation where we use strcmp, I would expect to see this bug. In the situation where we do not use strcmp, I would not expect to see that bug -- because I would expect that the type_info objects and the corresponding type_info strings are local symbols. If that is not the case, then that is the bug. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: resolving backslash newline whisky tango foxtrot: a proposal
Joe Buck wrote: > So the amended suggestion is to fix -Wcomment to shut up about continued > comments that don't matter, and also to add the new -f option to switch > the handling of spaces-at-the-end. I think your proposal, as amended, is the right approach. I generally don't much like new command-line options, but I agree that this is a situation in which both sides have valid points, there's legacy code around that depends on both behaviors, and having a switch makes sense. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Exception propagation problem on IA-64/Linux
> This test case is valid, and the results observed are in incorrect; in > other words, yes, there is a bug. Thanks for confirming. > In general, comparison of type_info objects is supposed to be done by > checking for address equality of the type info strings. On systems > without weak symbols, we use strcmp. (Look for > __GXX_MERGED_TYPEINFO_NAMES in .) In the situation where we > use strcmp, I would expect to see this bug. In the situation where we > do not use strcmp, I would not expect to see that bug -- because I would > expect that the type_info objects and the corresponding type_info > strings are local symbols. If that is not the case, then that is the bug. data1 0x1 // Action record table data1 0x0 .align 8 data8.ua@gprel(DW.ref._ZTIZ3foovE1S#) .hidden DW.ref._ZTIZ3foovE1S .weak DW.ref._ZTIZ3foovE1S# .section.gnu.linkonce.s.DW.ref._ZTIZ3foovE1S,"aws",@progbits .align 8 .type DW.ref._ZTIZ3foovE1S#, @object .size DW.ref._ZTIZ3foovE1S#, 8 DW.ref._ZTIZ3foovE1S: data8 _ZTIZ3foovE1S# Found both in u.S and t.S and merged by the linker. -- Eric Botcazou
Re: svn troubles
Ralf Corsepius <[EMAIL PROTECTED]> writes: > Hi, > > I don't seem to be able to access svn: > > # svn ls svn://gcc.gnu.org/svn/gcc > [several (2-3) minutes pass, during which svn is non-interruptable] > svn: Can't connect to host 'gcc.gnu.org': Connection timed out I didn't read that it's up again after the switch from CVS to SVN - I suggest to wait until Danny sends the announcement, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgprJVanzU8DP.pgp Description: PGP signature
Re: svn troubles
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I don't seem to be able to access svn: > > > > # svn ls svn://gcc.gnu.org/svn/gcc > > [several (2-3) minutes pass, during which svn is non-interruptable] > > svn: Can't connect to host 'gcc.gnu.org': Connection timed out > > I didn't read that it's up again after the switch from CVS to SVN - I > suggest to wait until Danny sends the announcement, OK, sorry, I must have missed this in all the svn related mail floods. Ralf
