headers
Patrick Moran | 1 Jul 2009 05:48
Picon

Re: Forcing the production of unreachable code

Hello all,
   I was wondering if there is some means of directing gcc to generate
unreachable code?  Either a means to do so globally or a specific
scope would be great.  I wish to generate some code which employs
inline assembly and/or libunwind to do a type of exception handling
not possible in standard C.

   Don't get me wrong - the compiler is correct. The generated code is
unreachable via any standard C control flow mechanism, but I'd really
like it to generate the code anyways.  Is there any way to do this?

Thanks,
Patrick Moran
Permalink | Reply | 2 comments |
headers
Jeff Law | 1 Jul 2009 06:04
Picon
Favicon

Re: Forcing the production of unreachable code

Patrick Moran wrote:
> Hello all,
>    I was wondering if there is some means of directing gcc to generate
> unreachable code?  Either a means to do so globally or a specific
> scope would be great.  I wish to generate some code which employs
> inline assembly and/or libunwind to do a type of exception handling
> not possible in standard C.
>
>    Don't get me wrong - the compiler is correct. The generated code is
> unreachable via any standard C control flow mechanism, but I'd really
> like it to generate the code anyways.  Is there any way to do this?
>   
Put a label before the block of code, then take the address of the label 
and pass it to a function defined in another compilation unit?   That 
should make the compiler think the code in question is reachable and 
thus prevent it from being deleted.

jeff
Permalink | Reply | 1 comment |
headers
Patrick Moran | 1 Jul 2009 06:30
Picon

Re: Forcing the production of unreachable code

Thanks for the reply.

I had thought this would work as well, but consider the following code:

void elsewhere(void* ptr);
int main()
{
  elsewhere( && LABEL );
  return 0;
 LABEL: __asm__(";look at me");
}

Compiling this with `gcc -O0 -S -Wunreachable-code unreach.c` produces
a warning calling the label unreachable.  In fact, visual inspection
of the produced assembly confirms that the comment "look at me" is not
generated.

This is on the gcc 4.1.2 distributed by Gentoo, with equivalent
remarks on Debian's gcc, whose version I don't know at the moment.

The only means I've found of `tricking` gcc into thinking code is
reachable is to place a goto to it inside a conditional whose
condition depends upon a global or volatile variable ( that is always
false in reality ).  However, the code I'm generating would have one
of these unreachable blocks in every function, so that's a lot of
volatile variables and/or globals to mess up the optimizer and/or
cache locality.

What would be ideal (and it might not be possible, but that's what I'm
asking) is if there's some way to either a) generate  code despite its
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dr. David Kirkby | 1 Jul 2009 11:47

gcc 4.4.0 on SPARC - optimisation problem

On a Sun T5240 (16 core device, 32 GM RAM, countless TB of disk space) 
I installed gcc 4.4.0. The computer was kindly donated by Sun to the 
University of Washington for the Sage project.

http://www.sagemath.org/

The method I used to create gcc 4.4.0 was

1) Compiled GMP 4.3.1 with the compiler supplied by Sun 
(/usr/sfw/bin/gcc), which is version 3.4.3 of gcc. All GMP tests passed.

2) Compiled  MPFR 2.4.1. All tests passed

3) Buuild gcc 4.4.0 with:

kirkby <at> t2:[~] $ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /home/kirkby/gcc-4.4.0/configure CC=/usr/sfw/bin/gcc 
--prefix=/usr/local/gcc-4.4.0-sun-linker --without-gnu-as 
--without-gnu-ld --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld 
--enable-languages=c,c++,fortran --with-mpfr-lib=/usr/local/lib 
--with-mpfr-include=/usr/local/include 
--with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib 
--with-libiconv-prefix=/usr/lib/iconv
Thread model: posix
gcc version 4.4.0 (GCC)

Now if I build MPFR, with no optimisation, all 148 tests pass. Build 
MPFR with -O1 or -O2 and 20 tests fail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
vinod | 1 Jul 2009 15:07
Picon

undefined reference to `main'

Hi all :
When I using gcc to compile my code.c to code , I got the error msg as
follows :
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function
`_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status

What can I do now, any suggestion?
Vinod
Permalink | Reply | 3 comments |
headers
Andrew Haley | 1 Jul 2009 15:08
Picon
Favicon

Re: FW: undefined reference to `main'

vinod wrote:
>  
> 
> Hi Andrew..
> 
> When I using gcc to compile my code.c to code , I got the error msg as
> follows :
> 
>  
> 
> /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function
> `_start':
> 
> (.text+0x18): undefined reference to `main'
> 
> collect2: ld returned 1 exit status
> 
>  
> 
>  
> 
>  
> 
> What can I do now, any suggestion?

Give us a test case: the program you're trying to compile and the command
you're using to compile it.

Andrew.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Ruottu | 1 Jul 2009 16:06

Re: undefined reference to `main'

vinod wrote:

> When I using gcc to compile my code.c to code , I got the error msg as
> follows :
> /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function
> `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status

Could it be possible that you haven't the function 'main()' in your C
application ?

Maybe the current C courses and books teach that "C programs always
start from WinMain()"... :)
Permalink | Reply | 0 comments |
headers
Kai Ruottu | 1 Jul 2009 16:20

Re: undefined reference to `main'

vinod wrote:

> When I using gcc to compile my code.c to code , I got the error msg as
> follows :
> /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function
> `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status
> 
> What can I do now, any suggestion?

Please read the book :

http://www.crasseux.com/books/ctut.pdf

also a manual for glibc, GCC etc. could be useful in your own library...
Or reading them online. Like :

http://www.gnu.org/software/libc/manual/
Permalink | Reply | 1 comment |
headers
Marcus Clyne | 1 Jul 2009 18:16
Picon

Problems compiling using GCC in execvp

Hi,

I'm having some issues when trying to compile some files when using 
execvp to launch GCC.

I'm basically forking, then calling

execvp (bin, argv);

Where bin is a char* to "gcc" and argv is a pointer to the array of 
char* below:

-fPIC
-o
/tmp/simpl-so/objs/783b8f28.o
-I
/simpl/dev/src
-I
/simpl/dev/src/core
-I
/simpl/dev/src/include
-c
/t/bufout.c

I am getting the following output from the compiler:

--------------------------------------------

In file included from /usr/include/semaphore.h:23,
                 from /simpl/dev/src/include/simpl_system.h:3,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marcus Clyne | 1 Jul 2009 18:39
Picon

Re: Problems compiling using GCC in execvp

I think the problem is with the permissions on the folders where 
stddef.h and some other folders are - given at the bottom.

Ignore this issue.

Marcus.

Marcus Clyne wrote:
> Hi,
>
> I'm having some issues when trying to compile some files when using 
> execvp to launch GCC.
>
> I'm basically forking, then calling
>
> execvp (bin, argv);
>
> Where bin is a char* to "gcc" and argv is a pointer to the array of 
> char* below:
>
> -fPIC
> -o
> /tmp/simpl-so/objs/783b8f28.o
> -I
> /simpl/dev/src
> -I
> /simpl/dev/src/core
> -I
> /simpl/dev/src/include
> -c
(Continue reading)

Permalink | Reply | 0 comments |

Gmane