Re: proposed Opengroup action for c99 command (XCU ERN 76)
> > A. Convert everything to UCNs in basic source characters as soon > > as possible, that is, in translation phase 1. (This is what > > C++ requires, apparently.) > > > > B. Use native encodings where possible, UCNs otherwise. > > > > C. Convert everything to wide characters as soon as possible > > using an internal encoding that encompasses the entire source > > character set and all UCNs. > > Now, see libcpp/charset.c. See the -finput-charset= option. To me > that looks like code which does something related to (A), (B), or (C). Well, maybe I'm missing something, but it never converts input characters to UCNs so that means it doesn't do (A) or (B), and the only thing it converts to wide characters are wide string literals, so it doesn't do (C). Hmm... maybe it's doing (B) if UCNs aren't ever necessary, though it doesn't seem to support extended characters in indentifiers so it's not quite using native encodings where possible. Though the intent does seem to be to go with option (B). Ross Ridge
lib2funcs and fpbit both rely on each other
Hello, When building Libgcc with new porting gcc, _floatdidf.o failed for undefined symbol _floatsidf. I've been told that _floatsidf is in fpbit.c as _si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit. But _pack_df.o failed for undefined symbol _ashldi3.o which is in libgcc2.c. It seems that they are rely on both each other. Thanks again. Eric
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: Well, maybe I'm missing something, but it never converts input characters to UCNs so that means it doesn't do (A) or (B), and the only thing it converts to wide characters are wide string literals, so it doesn't do (C). You are thinking operationally, when you should think semantically. Remember that as-if applies here. The rules as stated give ways to achieve certain effects, the question is not whether we are following the operational rules, but whether we are following the effects. Indeed I am not sure I understand that the three options are in fact distinct semantically. Can someone who understands this better address this point, and explain what the observable semantic effects of the three approaches are and how they differ.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
On Wed, 14 Sep 2005, Paul Eggert wrote: > So my question is: Is it a burden on GCC to require interpretation (B)? Yes, but my position remains that we *should* aim to implement (B) and this is a proper burden to impose. For how the interpretations can be distinguished, see bug 9449 comments 21 et seq (especially the examples in comment 39). -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
GCC 4.0.1 build succeeded using Fedora Core 4
GCC 4.0.1 has been succesfully built on Fedora Core 4 - hardware: Intel Celeron 2.0 GHz 512 MB RAM - download: gcc-4.0.1.tar.bz2 - installation steps configure make bootstrap make install - output from running config.guess i686-pc-linux-gnu - output of gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/gcc-4.0.1/configure Thread model: posix gcc version 4.0.1 - languages: default - Linux - distribution Fedora Core 4 - uname -a Linux localhost.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun2 22:55:56 EDT 2005 i686 i686 i386 GNU/Linux - glibc glibc-2.3.5-10 -- Eduardo Restuccia www.handsoft.com.uy Montevideo - Uruguay
Re: lib2funcs and fpbit both rely on each other
On Thursday 15 September 2005 10:59, Eric Fisher wrote: > Hello, > > When building Libgcc with new porting gcc, _floatdidf.o failed for > undefined symbol > _floatsidf. I've been told that _floatsidf is in fpbit.c as > _si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit. > But _pack_df.o failed for undefined symbol > _ashldi3.o which is in libgcc2.c. It seems that they are rely on both > each other. Sounds like your assembler is broken. Building libgcc shouldn't require linking anything, so you should never get undefined symbols when building libgcc.a. Paul
Re: checksum files not ^C safe
On Sep 15, 2005, Geoffrey Keating <[EMAIL PROTECTED]> wrote: > On 14/09/2005, at 5:32 PM, Mike Stump wrote: >> If you output to a temp file, and then mv them to the final file, >> they will be (I think) safe. > From the 'make' documentation, node 'Interrupts': >> If `make' gets a fatal signal while a command is executing, it may >> delete the target file that the command was supposed to update. >> This is >> done if the target file's last-modification time has changed since >> `make' first checked it. > So, I think this is safe. The file will be deleted and then re-built > next time you run 'make'. That unfortunately doesn't cover power failures and so, which may leave an incomplete file behind. The use of a temp file has been the right approach, recommended forever, and used all over the place in the GCC build machinery. -- 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}
Re: When is it legal to compare any pair of pointers?
On Sep 14, 2005, Joe Buck <[EMAIL PROTECTED]> wrote: > On Wed, Sep 14, 2005 at 02:15:43PM -0300, Alexandre Oliva wrote: >> Yep, it was pointer subtraction, and GCC actually optimized the >> division, that could in theory be assumed to be exact, into a >> multiplication by a large constant (aah, the wonders of modulo >> arithmetics :-) > People that don't like the GCC optimization It's not entirely clear that you got the impression I didn't like it. I have no objection at all, I was just providing the additional details as to the bug we'd run into because of unspecified uses of pointer subtraction, as requested by DanJ. -- 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}
RE: lib2funcs and fpbit both rely on each other
Original Message >From: Paul Brook >Sent: 15 September 2005 14:25 > On Thursday 15 September 2005 10:59, Eric Fisher wrote: >> Hello, >> >> When building Libgcc with new porting gcc, _floatdidf.o failed for >> undefined symbol _floatsidf. I've been told that _floatsidf is in >> fpbit.c as _si_to_df.o. Then I modified the libgcc.mk and firstly build >> fpbit. But _pack_df.o failed for undefined symbol >> _ashldi3.o which is in libgcc2.c. It seems that they are rely on both >> each other. > > Sounds like your assembler is broken. Building libgcc shouldn't require > linking anything, so you should never get undefined symbols when building > libgcc.a. Indeed. And isn't modifying libgcc.mk, like, totally the wrong thing to do? I thought you were only supposed to modify your t-* target makefile frag: `Floating Point Emulation' To have GCC include software floating point libraries in `libgcc.a' define `FPBIT' and `DPBIT' along with a few rules as follows: # We want fine grained libraries, so use the new code # to build the floating point emulation libraries. FPBIT = fp-bit.c DPBIT = dp-bit.c fp-bit.c: $(srcdir)/config/fp-bit.c echo '#define FLOAT' > fp-bit.c cat $(srcdir)/config/fp-bit.c >> fp-bit.c dp-bit.c: $(srcdir)/config/fp-bit.c cat $(srcdir)/config/fp-bit.c > dp-bit.c You may need to provide additional #defines at the beginning of `fp-bit.c' and `dp-bit.c' to control target endianness and other options. cheers, DaveK -- Can't think of a witty .sigline today
"TCP retransmission" in Downloading from GDB
Hi, In GDB, when I use the following commands : $ powerpc-eabi-gdb 543560.elf GNU gdb 6.1 (eCosCentric) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"... (gdb) target remote 192.168.1.3:9000 Remote debugging using 192.168.1.3:9000 0x00014528 in ?? () warning: no shared library support for this OS / ABI (gdb) load Loading section .text, size 0x7ac2c lma 0x71000 Loading section .rodata, size 0x9ff0 lma 0xebc30 Loading section .eh_frame, size 0x94 lma 0xf5c20 Loading section .data, size 0x1e51 lma 0xf5cb8 Start address 0x71000, load size 551681 Transfer rate: 49038 bits/sec, 510 bytes/write. (gdb) the transfer rate of the download is very slow (up to 120 seconds) and I notice via an Ethernet Analyser that there are a lot of "TCP Retransmission" that explain the problem. But when I use the GUI GDB with the "powerpc-eabi-insight" command and I download the same elf file, there are no "TCP Retransmission" and it takes just 2 seconds for downloading. I don't understand what are the TCP difference between the GUI and the CLI of GDB. Does someone get the same differences on TCP between GUI and CLI ? Do I forget a GDB option in the CLI GDB command ? Thanks, Emmanuel Coullien NOTE : CE COURRIER ELECTRONIQUE EST DESTINE EXCLUSIVEMENT AU(X) DESTINATAIRE(S) MENTIONNE(S) CI-DESSUS ET PEUT CONTENIR DES INFORMATIONS PRIVILEGIEES, CONFIDENTIELLES ET/OU ET/OU NON SOUMISES A DIVULGATION AUX TERMES DES LOIS APPLICABLES . SI VOUS AVEZ RECU CE MESSAGE PAR ERREUR , OU S'IL NE VOUS EST PAS DESTINE, VEUILLEZ LES SIGNALER IMMEDIATEMENT A L'EXPEDITEUR ET EFFACER CE COURRIER ELECTRONIQUE. NOTE: This e-mail message is intended only for the named recipient(s) above and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
RE: "TCP retransmission" in Downloading from GDB
Original Message >From: e.coullien >Sent: 15 September 2005 15:05 > Hi, > > In GDB, Wrong list. This is the gcc list. You were right first time when you posted this exact same message to the gdb list half an hour ago. cheers, DaveK -- Can't think of a witty .sigline today
Re: "TCP retransmission" in Downloading from GDB
Dave Korn <[EMAIL PROTECTED]> wrote: > Wrong list. This is the gcc list. You were right first time when you > posted this exact same message to the gdb list half an hour ago. Moreover, people have surely already deleted his message beacuse the disclaimer at the end of it explicitally says that you must delete the mail if you are not the intended recipient. I am not gcc@gcc.gnu.org, so I deleted his message. Emmanuel, you should read the section "Policies" at http://gcc.gnu.org/lists.html before posting again. -- Giovanni Bajo
Re: GCC 4.0.2 RC1 Available
Ulrich Weigand wrote: > Mark Mitchell wrote: > > >>It's important to test the actual tarballs, rather than CVS, to check >>for any packaging issues. If you can, download and build the tarballs, >>post test results to the gcc-testresults mailing list with and >>contrib/test_summary. If you encounter problems, please file them in >>bugzilla, and add me to the CC: list. > > > s390(x)-ibm-linux are looking good: > http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00688.html > http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00689.html Thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 RC1 Available
Laurent GUERBY wrote: > On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote: > >>Assuming that no critical problems emerge, I'll do the final release >>within the next week. > > > Looks good on x86-linux and x86_64-linux for Ada: Thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 RC1 Available
Mark Mitchell wrote: It's important to test the actual tarballs, rather than CVS, to check for any packaging issues. If you can, download and build the tarballs, post test results to the gcc-testresults mailing list with and contrib/test_summary. If you encounter problems, please file them in bugzilla, and add me to the CC: list. I have a build of all the RTEMS targets going now. It will take a while to crank through them all but feedback will be coming. II have binutils installed for the following targets so that is what I am trying. arm-rtems4.7 avr-rtems4.7 h8300-rtems4.7 h8300-rtemscoff4.7 i386-rtems4.7 m68k-rtems4.7 mips64-rtems4.7 mips-rtems4.7 powerpc-rtems4.7 sh-rtems4.7 sh-rtemscoff4.7 sparc-rtems4.7 tic4x-rtems4.7 I noticed a couple of those should show deprecated or obsoleted in the build logs so I can verify that. Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: > >Well, maybe I'm missing something, but it never converts input characters > >to UCNs so that means it doesn't do (A) or (B), and the only thing it > >converts to wide characters are wide string literals, so it doesn't do > >(C). On Thu, Sep 15, 2005 at 07:24:47AM -0400, Robert Dewar wrote: > You are thinking operationally, when you should think semantically. > Remember that as-if applies here. The rules as stated give ways to > achieve certain effects, the question is not whether we are following > the operational rules, but whether we are following the effects. This was exactly my point when I asked for an example. Joseph Myers pointed to some, in the discussion for PR 9449 (particularly comment #39). The examples, however, are obscure enough that users might prefer having a few corner-case bugs to a rigorously correct, but slower, implementation. For example, if the cost of correctly handling #define foo \u00b1 #define foo \u00B1 /* invalid: different spelling in replacement */ #define \u00c1 foo #define \u00C1 foo /* valid: spelling of macro *name* can vary */ is a 10% slowdown in preprocessor speed, I'd rather leave it broken and document the breakage. On the other hand, if a correct implementation of these rules does not impose a speed penalty, wonderful. It is truly annoying that the C and C++ committees created different rules, BTW.
Re: checksum files not ^C safe
On Sep 14, 2005, at 11:55 PM, Geoffrey Keating wrote: So, I think this is safe. My build system (GNU make 3.80 on darwin) disagrees with your theory, I saw two zero length files, created from one -j2 build interrupted with a normal ^C. I usually never so interrupt builds, so the probability of failure is higher than one might otherwise expect.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
> You are thinking operationally, when you should think semantically. > Remember that as-if applies here. The rules as stated give ways to > achieve certain effects, the question is not whether we are following > the operational rules, but whether we are following the effects. Thinking semantically is irrelevent because the question isn't whether GCC conforms to C99 or POSIX. It clearly doesn't. GCC fails the as-if rule. The question is one of implementation burden, which can only be answered by examining GCC's implementation. > Indeed I am not sure I understand that the three options are in fact > distinct semantically. The aren't in C99, as Paul Eggert's original message made clear, but they are in an environment that defines a command like "c99" that makes preprocessed output visable. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: RFA: pervasive SSE codegen inefficiency
On Sep 14, 2005, at 9:50 PM, Andrew Pinski wrote: On Sep 14, 2005, at 9:21 PM, Dale Johannesen wrote: Consider the following SSE code (-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2) <4256776a.c> The first inner loop compiles to paddq %xmm0, %xmm1 Good. The second compiles to movdqa %xmm2, %xmm0 paddw %xmm1, %xmm0 movdqa %xmm0, %xmm1 when it could be using a single paddw. The basic problem is that our approach defines __m128i to be V2DI even though all the operations on the object are V4SI, so there are a lot of subreg's that don't need to generate code. I'd like to fix this, but am not sure how to go about it. From real looks of this looks more like a register allocation issue and nothing to do with subregs at all, except subregs being there. That's kind of an overstatement; obviously getting rid of the subregs would solve the problem as you can see from the first function. I think you're right that If we allocated 64 and 63 as the same register, it would have worked correctly. (you mean 64 and 66) would fix this example; I'll look at that. Having a more uniform representation for operations on __m128i objects would simplify things all over the place, though.
Re: RFA: pervasive SSE codegen inefficiency
On Thu, Sep 15, 2005 at 11:07:23AM -0700, Dale Johannesen wrote: > Having a more uniform representation for operations on __m128i > objects would simplify things all over the place, though. For some definition of "simplify" that doesn't actually make things simpler when it comes to the autovectorizer. Please leave things in their "natural" operational mode and fix the register allocator. r~
RFC: dbxout_type rewrite
GCC routinely puts on the fly type description in other stabs. For example, 006c - 00 0002 PSYM argv:p(0,2)=*(0,3)=*(0,4)=r(0,4);0;127; Now when this PSYM stab is discarded by linker the useful type info is lost. This happens a lot in -feliminate-unused-debug-symbols mode. It happens even more in GCC-4.0 compared to GCC-3.3. Plus it is useful to put avoid on the fly type descriptions for the Essential Symbols work done here at Apple. And one small thing, it is less confusing to GDB when type is described first before being used. (And that is in -feliminate-unused-debug-symbols mode :)). So instead of generating these stabs - 01 0003 FUN main:F(0,1) - 00 LSYM int:t(0,1)=r(0,1);-2147483648;2147483647; 0068 - 00 0002 PSYM argc:p(0,1) 006c - 00 0002 PSYM argv:p(0,2)=*(0,3)=*(0,4) - 00 LSYM char:t(0,4)=r(0,4);0;127; 004c - 00 FUN It is desirable that GCC produces this - 01 0003 FUN main:F(0,1) 0068 - 00 0002 PSYM argc:p(0,1) 006c - 00 0002 PSYM argv:p(0,2) - 00 LSYM int:t(0,1)=r(0,1);-2147483648;2147483647; - 00 LSYM :t(0,2)=*(0,3) - 00 LSYM :t(0,3)=*(0,4) - 00 LSYM char:t(0,4)=r(0,4);0;127; 004c - 00 FUN I've now patch ready (based on apple-local-200502-branch) but it requires few bug fixes in darwin GDB. My simple question is : Is anybody interested in reviewing this GCC patch for acceptance in FSF GCC (4.1 or 4.2 or whenever) irrespective of whether associated GDB changes are contributed or not? Apple linker is updated to avoid 't' and 'T' LSYM stabs while removing chunks of stabs. I am not sure how big deal it is for FSF linker. And I do not know whether these linker changes will find its way in FSF linker or not. I know, this is about stabs and not many folks care about stabs. And on top of that it is related to -feliminate-unused-debug-symbols mode mainly. Plus issue of getting other tools on the same page. So I'd like to understand the interest before sending patch (and later on annoying ping messages :) ). [ Do not say anything about switching to Dwarf. Other folks here at Apple are working on it. ] - Devang
Re: RFC: dbxout_type rewrite
On Sep 15, 2005, at 2:26 PM, Devang Patel wrote: I've now patch ready (based on apple-local-200502-branch) but it requires few bug fixes in darwin GDB. My simple question is : Is anybody interested in reviewing this GCC patch for acceptance in FSF GCC (4.1 or 4.2 or whenever) irrespective of whether associated GDB changes are contributed or not? Apple linker is updated to avoid 't' and 'T' LSYM stabs while removing chunks of stabs. I am not sure how big deal it is for FSF linker. And I do not know whether these linker changes will find its way in FSF linker or not. The only issue I can see is that someone who uses an older versions of Mac OS X but don't have access to the newer GDB because building Apple's version of GDB is a little harder than building than gcc. If you provide a gdb version which is runnable on All of Mac OS X, this becomes a little mute, like the new cctools and stuff. Thanks, Andrew Pinski
Re: RFC: dbxout_type rewrite
The only issue I can see is that someone who uses an older versions of Mac OS X but don't have access to the newer GDB because building Apple's version of GDB is a little harder than building than gcc. If you provide a gdb version which is runnable on All of Mac OS X, this becomes a little mute, like the new cctools and stuff. I think you mean "moot", and it isn't because anyone else that wants stabs debugging would still need to change their debugger. Now, most people use dwarf, but the problem is still there. If people think it wouldn't be that much of a problem then I'm all about getting this patch in. -eric
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: Thinking semantically is irrelevent because the question isn't whether GCC conforms to C99 or POSIX. It clearly doesn't. GCC fails the as-if rule. The question is one of implementation burden, which can only be answered by examining GCC's implementation. Once again we are not discussing general conformance here, just conformance on this specific issue.
Duplicate dump file numbers
Paolo, I *think* this problem may have been caused by your reorg of the pass manager. We are now emitting duplicate dump file numbers: file.c.t10.cleanup_cfg file.c.t10.lower Could you take a look? Thanks.
Re: GCC 4.0.2 RC1 Available
Andreas Tobler wrote: On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote: Assuming that no critical problems emerge, I'll do the final release within the next week. Libgcj seems broken with --enable-java-awt=gtk,xlib --enable-gtk-cairo. (on darwin ppc and linux ppc at least, but I guess on all others too who uses the above config switches) Try to come up with a patch to fix the build. Ok, please ignore me. The changes in this area are to big to be incorporated into 4.0.2. (Means backporting from 4.1) So we have to live with the fact that one has to use a cairo version around 0.4.0 if he wants to build gcc with --enable-gtk-cairo. For higher cairo versions we recommend gcc-cvs head. Cairo has had a major revamp in the last months and the API has changed completely. This is the reason for the build failure if you use a recent cairo library. Side note, almost all libjava development work is concentrated in GNU classpath and the 4.0.x branch does not include classpath. This might be the reason why this slipped through, sorry. Andreas
Re: GCC 4.0.2 RC1 Available
> It's important to test the actual tarballs, rather than CVS, to check > for any packaging issues. If you can, download and build the tarballs, > post test results to the gcc-testresults mailing list with and > contrib/test_summary. sh4-unknown-linux-gnu is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00742.html Regards, kaz
Can we have a symbol_ref node of a declared symbol without having its flags set?
I ran into a problem when chasing down an -mfix-and-continue (an
apple specialty :) code-gen problem.
In a test case, ivopts creates a symbol_ref via a call to
produce_memory_decl_rtl; as in:
if (TREE_STATIC (obj) || DECL_EXTERNAL (obj))
{
const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(obj));
x = gen_rtx_SYMBOL_REF (Pmode, name);
}
...
But it does not set the flags for this symbol. This causes code gen
problem in certain cases ; such as in apple-ppc-darwin PIC generation
code, which rely on these flags. An obvious fix come to mind is to
set the flags when symbol_ref is created. Such as in this patch. But
a more general question is should we always set the flags for
symbol_ref whenever such a node is created for a declared symbol?
--- 2376,2404
static rtx
produce_memory_decl_rtl (tree obj, int *regno)
{
! rtx x, ret;
if (!obj)
abort ();
if (TREE_STATIC (obj) || DECL_EXTERNAL (obj))
{
const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(obj));
x = gen_rtx_SYMBOL_REF (Pmode, name);
+ ret = gen_rtx_MEM (DECL_MODE (obj), x);
+ SET_DECL_RTL (obj, ret);
+ targetm.encode_section_info (obj, DECL_RTL (obj), true);
}
else
! {
! x = gen_raw_REG (Pmode, (*regno)++);
! ret = gen_rtx_MEM (DECL_MODE (obj), x);
! }
! return ret;
}
Thanks, fariborz ([EMAIL PROTECTED])
Re: lib2funcs and fpbit both rely on each other
2005/9/15, Paul Brook <[EMAIL PROTECTED]>: > On Thursday 15 September 2005 10:59, Eric Fisher wrote: > > Hello, > > > > When building Libgcc with new porting gcc, _floatdidf.o failed for > > undefined symbol > > _floatsidf. I've been told that _floatsidf is in fpbit.c as > > _si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit. > > But _pack_df.o failed for undefined symbol > > _ashldi3.o which is in libgcc2.c. It seems that they are rely on both > > each other. > > Sounds like your assembler is broken. Building libgcc shouldn't require > linking anything, so you should never get undefined symbols when building > libgcc.a. > > Paul > Thanks a lot. Indeed, the assembler gets wrong in handling of long jump. Your words takes me tumble to it and bring me out of a week's puzzle. Cheers. Eric
Re: Can we have a symbol_ref node of a declared symbol without having its flags set?
On Thu, Sep 15, 2005 at 04:45:11PM -0700, Fariborz Jahanian wrote: > But > a more general question is should we always set the flags for > symbol_ref whenever such a node is created for a declared symbol? Whenever it's created for real, yes. In this case we're just guessing at costs, so it ought not be 100% critical. r~
RFC: TLS improvements for IA32 and AMD64/EM64T
Over the past few months, I've been working on porting to IA32 and AMD64/EM64T the interesting bits of the TLS design I came up with for FR-V, achieving some impressive speedups along with slight code size reductions in the most common cases. Although the design is not set in stone yet, it's fully implemented and functional with patches I'm about to post for binutils, gcc and glibc mainline, as follow-ups to this message, except that the GCC patch will go to gcc-patches, as expected. The specs RFC is attached. Comments are welcome. Thread Local Storage Descriptors for IA32 and AMD64/EM64T Version 0.9.2 - 2005-09-15 Alexandre Oliva <[EMAIL PROTECTED], [EMAIL PROTECTED]> Introduction While porting NPTL to the FR-V architecture, an idea occurred to me that would enable significant improvements to the General Dynamic and Local Dynamic access models to thread-local variables. These methods are known to be extremely inefficient because of the need to call a function to obtain the address of a thread-local variable, a function that can often be quite inefficient. The reason for calling such a function is that, when code is compiled for a dynamic library (the cases in which these access models are used), it is not generally possible to know whether a thread-local variable is going to be allocated in the Static Thread Local Storage Block or not. Dynamic libraries that are loaded at program start up can have their thread local storage sections assigned to this static block, since their TLS requirements are all known before the program is initiated. Libraries loaded at a later time, however, may need dynamically-allocated storage for their TLS blocks. In the former case, the offset from the Thread Pointer, usually held in a register, to the thread-local variable is going to be the same for all threads, whereas in the latter case, such offset may vary, and it may even be necessary to allocate storage for the variable at the time it is accessed. Existing implementations of GD and LD access models did not take advantage of this run-time constant to speed up the case of libraries loaded before program start up, a case that is certainly the most common. Even though libraries can choose more efficient access models, they can only do so by giving up the ability for the modules that define such variables to be loaded after program start up, since different code sequences have to be generated in this case. The method proposed here doesn't make a compile-time trade off; it rather decides, at run time, how each variable can be accessed most efficiently, without any penalty on code or data sizes in case the variable is defined in an initially-loaded module, and with some additional data, allocated dynamically, for the case of late-loaded modules. In both cases, performance is improved over the traditional access models. Another advantage of this novel design for such access models is that it enables relocations to thread-local variables to be resolved lazily. Background == Thread-local storage is organized as follows: for every thread, two blocks of memory are allocated: a Static TLS block and a Dynamic Thread Vector. A thread pointer, normally a reserved register, points to some fixed location in the Static TLS block, that contains a pointer to the dynamic thread vector at some fixed location as well. TLS for the main executable, if it has a TLS section, is also at a fixed offset from the thread pointer. Other modules loaded before the program starts will also have their TLS sections assigned to the Static TLS block. The dynamic thread vector starts with a generation count, followed by pointers to TLS blocks holding thread-specific copies of the TLS sections of each module. If modules are loaded at run time, the dynamic thread vector may need to grow, and the corresponding TLS blocks may have to be allocated dynamically. The generation count is used to control whether the DTV is up-to-date with regard to newly-loaded or unloaded modules, enabling the reuse of entries without confusion on whether a TLS block has been created and initialized for a newly-loaded module or whether that block was used by a module already unloaded, that is still waiting for deallocation. Programs can access thread-local variables by using code that follows 4 different models: Local Exec, Initial Exec, General Dynamic and Local Dynamic. Local Exec is only applicable when code in the main executable accesses a thread-local variable also defined in the main executable. In such cases, the offset from the Thread Pointer to the variable can be computed by the linker, so the access model consists in simply adding this offset to the Thread Pointer to compute the address of the variable. Initial Exec is applicable when code in the main executable accesses thread-local variables that are defined in other loadable modules that are dependencies of this executable. Since the d
PR c++/11987: why is it invalid?
Mark, in PR c++/11987 you added a comment saying that it was a
regression. But the more I look at it, the less I understand it.
The test case is:
==
template struct X {
struct I { I(); };
};
template struct Y : X {
typedef typename X::I I;
};
template
Y::I::I () {} // note: I is nested type in X, not Y!
template struct Y<1>;
==
g++ currently accepts this test case. The PR says that this test case
is invalid, and should be rejected. But I can't figure out why. The
function definition using a typedef is clearly OK. Is the problem
specifically that this code declares a constructor using a template
specialization? That is, would this code be valid C++?
==
template struct X {
struct I { I(); void foo(); };
};
template struct Y : X {
typedef typename X::I I;
};
template
void Y::I::foo () {}
template struct Y<1>;
==
(Incidentally, this test case currently gets an ICE, but that is
presumably an unrelated problem.)
Or is the problem something else?
For what it's worth, I have a simple patch which rejects this code as
invalid and passes the g++ testsuite. But the patch seems fragile and
wrong. While trying to make the patch correct, I realized that I
don't understand what is correct.
Thanks.
Ian
Where are the fortran test results for cv strunk?
... just a quickie here... I just noticed that I don't see the fortran test results on cvs trunk anymore... I suppose this might be related to the change of name from f95/gfortran to fortran... -- Cheers, /ChJ
