Re: gcc detect multiple -o passed on one command line
Ian Lance Taylor writes: > The difference is that with -E the -o option is passed to cc1, whereas > without it the -o option is passed to the assembler or the linker. The > GNU assembler and linker both have the usual Unix behaviour of only > using the last -o option. Nevertheless it might be a good idea to file a bug for binutils. Consistency is probably more important, and it helps in case of typos. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: RFC: A new MIPS64 ABI
On Feb 15, 2011, David Daney wrote: > On 02/15/2011 09:56 AM, Alexandre Oliva wrote: >> On Feb 14, 2011, David Daney wrote: >> So, sorry if this is a dumb question, but wouldn't it be much easier to >> keep on using sign-extended addresses, and just make sure the kernel >> never allocates a virtual memory range that crosses a sign-bit change, > No, it is not possible. The MIPS (and MIPS64) hardware architecture > does not allow userspace access to addresses with the high bit (two > bits for mips64) set. Interesting. I guess this makes it far easier to transition to the u32 ABI: n32 addresses all have the 32-bit MSB bit clear, so n32 binaries can be used within u32 environments, as long as the environment refrains from using addresses that have the MSB bit set. So we could switch lib32 to u32, have a machine-specific bit set for u32 binaries, and if the kernel starts an executable or interpreter that has that bit clear, it will refrain from allocating any n32-invalid address for that process. Furthermore, libc, upon loading a library, should be able to notify the kernel when an n32 library is to be loaded, to which the kernel would respond either with failure (if that process already uses u32-valid but n32-invalid addresses) or success (switching to n32 mode if not in it already). Am I missing any other issues? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Unwinding through exception handlers when PC is NULL.
On Fri, May 6, 2011 at 3:24 AM, David Daney wrote:
> Consider this program under GNU/Linux (x86_64):
>
> - np.c ---
> #include
> #include
> #include
> #include
>
> static void handler(int sig)
> {
> printf("got signal %d\n", sig);
> throw 1;
> }
>
> int (*my_vector)(int);
>
> int *bar;
>
> int main(int argc, char *argv[])
> {
> struct sigaction sa;
> memset(&sa, 0, sizeof(sa));
>
> sa.sa_handler = handler;
> sa.sa_flags = SA_RESTART;
> sigemptyset(&sa.sa_mask);
>
> int rv = sigaction(SIGSEGV, &sa, NULL);
> if (rv) {
> perror("sigaction failed");
> exit(1);
> }
>
> try {
> //*bar = 6;
> rv = my_vector(0);
> } catch (int c) {
> printf("I cought %d\n", c);
> exit(0);
> }
>
> printf("No exception\n");
> return 0;
> }
> --8<-
>
> $ g++ -fnon-call-exceptions -o np np.cc
> $ ./np
> got signal 11
> terminate called after throwing an instance of 'int'
> Aborted (core dumped)
>
>
> However if we uncomment the '//*bar = 6;' line we get:
>
> $ ./np
> got signal 11
> I cought 1
>
> This happens because the libgcc unwinder cannot find unwinding information
> for the PC at the point of the SIGSEGV.
>
> However, we know that usually when we end up with a PC of zero, it is
> because we called through a NULL function pointer. In this case, we could
> use the return address (perhaps with a slight adjustment to compensate for
> the call instruction) to do the unwinding.
>
> Would it make any sense to build something like this into libgcc?
>
> Or if we want to do this do we need to patch up the register state before
> executing the throw?
What happens if the indirect call is optimized to a jump via tailcall
optimization? We'd bogously skip one function then, no?
Richard.
> David Daney
>
gcc Pre-processor information
Problem Statement : Given a C file which has several macros defined (eg. #define MACRO 10) . I need to know what all macros are defined and their usage point(eg. line number) in the code. Need to know this information during or after gcc pre-processing phase. Possible solution may dump this macro information in some file. Is there any way that gcc can dump this information and if yes how? -- View this message in context: http://old.nabble.com/gcc-Pre-processor-information-tp31558009p31558009.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Unwinding through exception handlers when PC is NULL.
Richard Guenther writes: > What happens if the indirect call is optimized to a jump via tailcall > optimization? We'd bogously skip one function then, no? But that always happens with backtraces through tailcalls. It's nothing new. Ian
Re: gcc Pre-processor information
ankit writes: > Problem Statement : Given a C file which has several macros defined (eg. > #define MACRO 10) . I need to know what all macros are defined and their > usage point(eg. line number) in the code. > > Need to know this information during or after gcc pre-processing phase. > > Possible solution may dump this macro information in some file. > > Is there any way that gcc can dump this information and if yes how? Look at the implementation of -dD and the implementation of -g3. gcc does have this information, though it may not be in a particularly convenient form. Ian
IRA improvement patch
Hi Vlad,
I found a problem with your IRA improvement checkin r171649 on
29-3-2011. I can't get picochip port to build with this change. The
problem is in the function "clarify_prohibited_class_mode_regs" in
ira.c:1413. The code reproduced here is
/* Clarify IRA_PROHIBITED_CLASS_MODE_REGS by excluding hard registers
spanning from one register pressure class to another one. It is
called after defining the pressure classes. */
static void
clarify_prohibited_class_mode_regs (void)
{
int j, k, hard_regno, cl, pclass, nregs;
for (cl = (int) N_REG_CLASSES - 1; cl >= 0; cl--)
for (j = 0; j < NUM_MACHINE_MODES; j++)
for (k = ira_class_hard_regs_num[cl] - 1; k >= 0; k--)
{
hard_regno = ira_class_hard_regs[cl][k];
if (TEST_HARD_REG_BIT (ira_prohibited_class_mode_regs[cl][j],
hard_regno))
continue;
nregs = hard_regno_nregs[hard_regno][j];
pclass = ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno)];
for (nregs-- ;nregs >= 0; nregs--)
if (((enum reg_class) pclass
!= ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno + nregs)]))
{
SET_HARD_REG_BIT (ira_prohibited_class_mode_regs[cl][j],
hard_regno);
break;
}
}
}
I do not understand the functionality of the code, but i get a segfault
in the line
if (((enum reg_class) pclass
!= ira_pressure_class_translate[REGNO_REG_CLASS
(hard_regno + nregs)]))
In the case where it segfaults, the hard_regno+nregs is greater than
FIRST_PSEUDO_REGISTER. It leads to access beyond the end of
REGNO_REG_CLASS array.
I realise that hard_regno_nregs happily gives you a value beyond the
FIRST_PSEUDO_REGISTER. I can change it so it wouldn't do that, if that
is the solution to this. Can you clarify?
Thanks
Hari
Re: gcc Pre-processor information
On 6 May 2011 12:25, ankit wrote: > > Problem Statement : Given a C file which has several macros defined (eg. > #define MACRO 10) . I need to know what all macros are defined and their > usage point(eg. line number) in the code. > > Need to know this information during or after gcc pre-processing phase. > > Possible solution may dump this macro information in some file. > > Is there any way that gcc can dump this information and if yes how? Please don't cross-post to both the gcc and gcc-help lists.
Re: Integration of transactional memory support into a data-flow extension of OpenMP
Dear Ismail, On Fri, 6 May 2011, ismail wrote: TinySTM 1.0 uses implicit transaction descriptor by default (same as 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and then the transaction descriptor is explicit. But functions are the same from 0.9.9 to 1.0.0 so I don't really see the problem. --- Yes . thanks for update , I remembered . Also I wrote the version wrong it is "0.9.0b1 release". There should be a parameter like EXPLICIT_TX_PARAMETER in trans-mem. Did you need a kind of parameter --- while compiling the trans-mem branch ? For example to use trans-mem to transactify LeeTM (I am especially talking about the MEMSET and MEMCPY funcs. of trans-mem do not have transaction identifier while accessing to the mem.). --- I am currently using the explicit function calls when I need transaction identifier as the following. Humm... libitm is always using implicit transaction descriptor and there is no such flag as in TinySTM. Don't confuse transaction descriptor and transaction identifier. I think it is better to use always implicit transaction descriptor it avoids the burden to manage it. --- I tried to get transaction handler which does not ---have explicit ---descriptor where another function needs transaction ---descriptor as ---a parameter. Hummm... which one has explicit tx descriptor? All ITM functions are using implicit transaction descriptor as far as I remember, otherwise it is a bit odd. Patrick.
Re: RFC: A new MIPS64 ABI
On 05/06/2011 01:29 AM, Alexandre Oliva wrote: On Feb 15, 2011, David Daney wrote: On 02/15/2011 09:56 AM, Alexandre Oliva wrote: On Feb 14, 2011, David Daney wrote: So, sorry if this is a dumb question, but wouldn't it be much easier to keep on using sign-extended addresses, and just make sure the kernel never allocates a virtual memory range that crosses a sign-bit change, No, it is not possible. The MIPS (and MIPS64) hardware architecture does not allow userspace access to addresses with the high bit (two bits for mips64) set. Interesting. I guess this makes it far easier to transition to the u32 ABI: n32 addresses all have the 32-bit MSB bit clear, so n32 binaries can be used within u32 environments, as long as the environment refrains from using addresses that have the MSB bit set. Correct. So we could switch lib32 to u32, have a machine-specific bit set for u32 binaries, and if the kernel starts an executable or interpreter that has that bit clear, it will refrain from allocating any n32-invalid address for that process. Furthermore, libc, upon loading a library, should be able to notify the kernel when an n32 library is to be loaded, to which the kernel would respond either with failure (if that process already uses u32-valid but n32-invalid addresses) or success (switching to n32 mode if not in it already). Am I missing any other issues? No, this is pretty much what Ralf and I came up with on IRC. We tag u32 objects (in a similar manner to how non-executable stack is done). The linker will propagate the u32 tag as it links things together. u32 shared libraries are compatible with legacy n32 binaries as long as the OS doesn't map any memory where the address has bit 31 set. When the OS loads an n32 executable it would check the u32 tag (both of the executable and ld.so) and adjust its memory allocation strategy. The OS will continue to map the VDSO at the 2GB point. This will cause the maximum size of any object to be compatible with the 32-bit n32 ptrdiff_t. I think once the OS puts a process into u32 mode, there is no going back. We would just have ld.so refuse to load any shared objects that were not compatible with the current mode. We would continue to place libraries in /lib32, /usr/lib32, /usr/local/lib32, etc. David Daney
Re: GAS GCC FAQ query
Hello. thank you for your reply. Jonathan Wakely wrote, On 05/05/11 22:47: On 5 May 2011 22:30, Jon Grant wrote: Hello Just looking at this page: http://gcc.gnu.org/faq.html#gas I saw this text "(the GNU loader)". Is this really an alternative name for gas? I've not seen it called GNU loader elsewhere. I was wondering if the text could just be removed. It refers to the linker, ld, not to gas, and shouldn't be removed. The parenthesized text represents an alternation, the paragraph should be read as referring to the GNU assembler or to the the GNU linker (aka loader). Not read "ld" called a "GNU loader" in binutils documentation, the common name I have seen is "GNU linker". (I do recall "ld" is an abbreviation for "load" though.) I would propose to clarify as: "To ensure that GCC finds the GNU assembler (or the GNU linker)," Best regards, Jon
Re: GAS GCC FAQ query
On 6 May 2011 21:19, Jon Grant wrote: > Hello. thank you for your reply. > > Jonathan Wakely wrote, On 05/05/11 22:47: >> >> On 5 May 2011 22:30, Jon Grant wrote: >>> >>> Hello >>> >>> Just looking at this page: >>> >>> http://gcc.gnu.org/faq.html#gas >>> >>> I saw this text "(the GNU loader)". Is this really an alternative name >>> for gas? I've not seen it called GNU loader elsewhere. I was wondering >>> if the text could just be removed. >> >> It refers to the linker, ld, not to gas, and shouldn't be removed. >> The parenthesized text represents an alternation, the paragraph should >> be read as referring to the GNU assembler or to the the GNU linker >> (aka loader). > > Not read "ld" called a "GNU loader" in binutils documentation, the common > name I have seen is "GNU linker". (I do recall "ld" is an abbreviation for > "load" though.) It's not a term I've seen often, but I have seen it. At http://en.wikipedia.org/wiki/Linker_(computing) Wikipedia says it's common on UNIX variants, and that FAQ is pretty old, so maybe it was written long ago by someone more versed in traditional unix terminology, before GNU/Linux was so prevalent. > I would propose to clarify as: > > "To ensure that GCC finds the GNU assembler (or the GNU linker)," I see no harm in that change, Gerald, what do you think?
gcc-4.6-20110506 is now available
Snapshot gcc-4.6-20110506 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110506/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 173516 You'll find: gcc-4.6-20110506.tar.bz2 Complete GCC (includes all of below) MD5=b848f2f4f6d2696a60c6e2a965b013cb SHA1=40357799c75cc83a88571174f3f1622cfab566b9 gcc-core-4.6-20110506.tar.bz2C front end and core compiler MD5=d4a916632fedc8e51b7d9d931f9324b9 SHA1=7d53235c845b55fbd348246260964015f1eec4fa gcc-ada-4.6-20110506.tar.bz2 Ada front end and runtime MD5=c1ce211fade6d594fe76ac1eb9b339d4 SHA1=ded64e525147305a7e1f6248b5bff0fd3c520f95 gcc-fortran-4.6-20110506.tar.bz2 Fortran front end and runtime MD5=ed855ae11dda06c6ca14b2ddb502c604 SHA1=138411738a6a05a29912e42c8cea3f3a956e7b0b gcc-g++-4.6-20110506.tar.bz2 C++ front end and runtime MD5=d18e184f59d278e60bc7f4d4c83b489f SHA1=2c6d55e2293b320fd797b596104f8f325137c947 gcc-go-4.6-20110506.tar.bz2 Go front end and runtime MD5=c0dea53ffebfb082e560bd3ea226323e SHA1=2b25d08d600db6e630e28c5f381a15b25c726736 gcc-java-4.6-20110506.tar.bz2Java front end and runtime MD5=b0e83840151671461e79befedf6ad862 SHA1=90299ee66bffacdc050196e87a0316cad138520c gcc-objc-4.6-20110506.tar.bz2Objective-C front end and runtime MD5=4e371f241730851438d6008457af03ca SHA1=e71b1612d39707192b457d24e1112fd0bbbee946 gcc-testsuite-4.6-20110506.tar.bz2 The GCC testsuite MD5=20b32459d0b40c8765df44f1c156c356 SHA1=788344ce4d2a3ff05c16acb70869c74eaf9229b8 Diffs from 4.6-20110429 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
