Re: How to Install GCC

On Sunday 11 March 2007 16:01, Thomas Schwinge wrote: > On Sun, Mar 11, 2007 at 10:45:53AM -0400, Sadri SARRAY wrote: > > Please, Would you like to send me a procedure to install the GCC > > compiler on a Linux-Ubuntu OS ? > > With a power screwdriver. Granted, poster was totally new to Linux and

gcc 4.1.1: char *p = "str" puts "str" into rodata

char p; int main() { p = ""; return 0; } Don't you think that "" should end up in rw data? /* .file "t.c" .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "" .text .globl main .type main, @function main: pushl %eb

Re: GCC4 makes off by ones more exploitable again, misuse of padding?

On Thursday 25 January 2007 01:43, In Cognito wrote: > > > 0x080483a7 :sub$0x208,%esp > > > 0x080483ad :mov0x8(%ebp),%eax > > > 0x080483b0 : mov%eax,0x4(%esp) > > > 0x080483b4 : lea0xfe00(%ebp),%eax > > > 0x080483ba : mov%eax,(%esp) > > > 0x080483bd : call

Re: GCC4 makes off by ones more exploitable again, misuse of padding?

On Thursday 25 January 2007 01:22, In Cognito wrote: > Hello, > > It's nice to see a more security-minded release of gcc with v4. > Variables are moved around to reduce chances for exploitation, > -fstack-protector, etc. Great! > > Why are local variables once-again adjacent to the saved frame po

Re: GCC optimizes integer overflow: bug or feature?

On Saturday 23 December 2006 10:06, Rask Ingemann Lambertsen wrote: >No, because you'd read past the end of the array: > > #include > > int main (int argc, char *argv[]) > { > char *a; > if ((a == malloc (sizeof (char > { > int r; > > a[0] = 1; > r = f (a); >

Re: GCC optimizes integer overflow: bug or feature?

On Friday 22 December 2006 03:03, Paul Brook wrote: > On Friday 22 December 2006 00:58, Denis Vlasenko wrote: > > On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: > > > There are a lot of 100.00% safe optimizations which gcc > > > can do. Value range propagation

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: > There are a lot of 100.00% safe optimizations which gcc > can do. Value range propagation for bitwise operations, for one Or this, absolutely typical C code. i386 arch can compare 16 bits at a time here (luckily, no alighment worr

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 22:46, Paul Brook wrote: > > Compiler can optimize it any way it wants, > > as long as result is the same as unoptimized one. > > We have an option for that. It's called -O0. > > Pretty much all optimization will change the behavior of your program. Even x*2 -> x+x? O

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 20:05, Andrew Haley wrote: > Denis Vlasenko writes: > > > > I wrote this just a few days ago: > > > > do { > > int32_t v1 = v << 1; > > if (v < 0) v1 ^= mask; > >

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 11:37, Paolo Bonzini wrote: > > > By the way, as I've tried to describe here: > > > > variable range tracking can result in reintroduction of > > supposedly-fixed security vulnerabilities. 8-( > > Interes

Re: distributing g++

On Friday 15 December 2006 22:30, Ferad Zyulkyarov wrote: > Hi > > > What are the standard practices with installing multiple versions of gcc > > on a system. I renamed this gcc to be gcc-4.1. However, it looks like it > > will still overwrite some files when I do 'make install'. Is this true? >

Re: distributing g++

On Friday 15 December 2006 22:30, Ferad Zyulkyarov wrote: > Hi > > > What are the standard practices with installing multiple versions of gcc > > on a system. I renamed this gcc to be gcc-4.1. However, it looks like it > > will still overwrite some files when I do 'make install'. Is this true? >

Re: g++ doesn't unroll a loop it should unroll

Disclaimer: I am not a compiler developer. On Wednesday 13 December 2006 12:44, Benoît Jacob wrote: > I'm developing a Free C++ template library (1) in which it is very important > that certain loops get unrolled, but at the same time I can't unroll them by > hand, because they depend on templat

Re: AVR byte swap optimization

On Saturday 18 November 2006 00:30, Shaun Jackman wrote: > The following macro expands to some rather frightful code on the AVR: > > #define BSWAP_16(x) \ > x) >> 8) & 0xff) | (((x) & 0xff) << 8)) Sometimes gcc is generating better code if you cast values instead of masking. Try:

Re: problem piping stdout

On Sunday 01 October 2006 15:34, Owen Lucas wrote: > > Im doing a program that reads in stuff from the serial port under linux. > Once read in there is a bit of formatting and it then needs to get piped > to something else. At the end is the cut down code. > > anyway the interesting part is in th

gcc-4.2-20060805: make bootstrap fails

Hello people, I tried to build and install gcc-4.2-20060805 snapshot. First, I needed to add some initializers. gcc seem to use -Werror at some stage and "might be used uninitialized" warnings were terminating the build. The patch is attached. Then "make bootstrap" failed in a different way: Th

Re: [PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 On Thursday 03 August 2006 06:55, Roger Sayle wrote: > As mentioned by Jim, the current GCC algorithm is based upon the > paper by Torbjorn Granlund and Peter Montgomery, "Division by > Invariant Integers using Multiplication", PLDI-94. > http://sw

Re: [PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()

On Tuesday 01 August 2006 00:34, Jim Wilson wrote: > Denis Vlasenko wrote: > > I still cannot figure out what precision is, so I restricted new code to > > (n == HOST_BITS_PER_WIDE_INT && precision == HOST_BITS_PER_WIDE_INT) case. > > Need help here. > > At t

Re: [PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()

On Wednesday 02 August 2006 08:30, Daniel Berlin wrote: > Denis Vlasenko wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 > > > > Right now Bugzilla internal problem prevents me from creating > > an attachement there. So it goes here. > > What problem

Re: if() and trailing ;

On Tuesday 01 August 2006 16:54, Gabriel Dos Reis wrote: > "Denis Vlasenko" <[EMAIL PROTECTED]> writes: > | if() > | (void)0; /* do nothing */ > | > | will make you happy. > > No, I'm not. I find it Very Silly. Do you prefer buggy code like this?

Re: if() and trailing ;

On 7/30/06, Joe Buck <[EMAIL PROTECTED]> wrote: On Sat, Jul 29, 2006 at 07:33:03PM -0400, Simon Boulet wrote: > After a couple hours debugging code, I figured our an if() somewhere > had a trailing ; like this: > > if (memcmp(p, COMMUNITY, strlen(COMMUNITY)) != 0); >

[PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 Right now Bugzilla internal problem prevents me from creating an attachement there. So it goes here. Not nice enough to go into release. I still cannot figure out what precision is, so I restricted new code to (n == HOST_BITS_PER_WIDE_INT && preci

Re: sorry, unimplemented: 64-bit mode not compiled in - ?!

On Thursday 27 July 2006 15:44, Daniel Jacobowitz wrote: > On Thu, Jul 27, 2006 at 12:56:14PM +0200, Denis Vlasenko wrote: > > does it mean I need a cross-compiler (to x86_64) to use -m64? > > It's strange because then -m64 is not useful at all > > - x86_64 cross compiler

building cross-compiler to x86_64. pthread.h: No such file

Hi, I am building gcc-4.1.1 like this: $SRC/configure \ --enable-languages="c,c++" \ --disable-nls \ --build=i386-pc-linux-gnu \ --host=i386-pc-linux-gnu\ --target=x86_64-pc-linux-gnu

sorry, unimplemented: 64-bit mode not compiled in - ?!

I imagine a lot of you gcc people will laugh at me now, but I finally bought amd64 machine and want to compile 64-bit Linux kernel. I am not able to do it. Tracked it down to a simple thing. My gcc cannot compile any .c file with -m64 flag: # gcc -m64 -c t.c t.c:1: sorry, unimplemented: 64-bit mo

Little help in understanding expmed.c::choose_multiplier()

I noticed that gcc's div-by-constant optimization is a bit suboptimal and want to improve it. I submitted it to bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 but I think "big guys" have no time for such a low-impact thing. I want to do it myself. However, I need a little helt in und

Re: Whirlpool oopses in 2.6.11 and 2.6.12-rc2

On Thursday 21 April 2005 06:16, James E Wilson wrote: > Denis Vlasenko wrote: > > Yes. wp512_process_buffer() was using 3k of stack if compiled with -O2. > > The wp512.c I appended (sans table at top) is instrumented to show it. > > Use "make crypto/wp512.s". >

Re: Whirlpool oopses in 2.6.11 and 2.6.12-rc2

On Tuesday 19 April 2005 20:40, Chris Wright wrote: > * Denis Vlasenko ([EMAIL PROTECTED]) wrote: > > On Tuesday 19 April 2005 08:42, Denis Vlasenko wrote: > > > modprobe tcrypt hangs the box on both kernels. > > > The last printks are: > > > > > >

Re: [BUG mm] "fixed" i386 memcpy inlining buggy

On Tuesday 05 April 2005 19:34, Christophe Saout wrote: > the new i386 memcpy macro is a ticking timebomb. > > I've been debugging a new mISDN crash, just to find out that a memcpy > was not inlined correctly. > > Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed). Updated patc

Re: [BUG mm] "fixed" i386 memcpy inlining buggy

On Tuesday 05 April 2005 19:34, Christophe Saout wrote: > Hi Denis, > > the new i386 memcpy macro is a ticking timebomb. > > I've been debugging a new mISDN crash, just to find out that a memcpy > was not inlined correctly. > > Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed)

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

On Saturday 02 April 2005 15:18, Denis Vlasenko wrote: > -O2 compile does inline copying, however, suboptimally. > Pushing/popping esi/edi on the stack is not needed. > Also "mov $1,ecx; rep; movsl" is rather silly. I think I am wrong about push/pop. Sorry. However, other o

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

> > childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) > > p->thread_info)) - 1; > > *childregs = *regs; > > ^^^ > > childregs->eax = 0; > > childregs->esp = esp; > > > > # make arch/i386/kernel/process.s > > > > copy_thread: >

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

On Wednesday 30 March 2005 05:27, Gerold Jury wrote: > > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote: > >> > /* > >> > * This looks horribly ugly, but the compiler can optimize it totally, > >> > * as the count i

Re: [PATCH] fix i386 memcpy

On Tuesday 29 March 2005 23:22, Denis Vlasenko wrote: > This patch shortens non-constant memcpy() by two bytes > and fixes spurious out-of-line constant memcpy(). > > Patch is run-tested (I run on patched kernel right now). > > Benchmark and code generation test program will

[PATCH] fix i386 memcpy

This patch shortens non-constant memcpy() by two bytes and fixes spurious out-of-line constant memcpy(). Patch is run-tested (I run on patched kernel right now). Benchmark and code generation test program will be mailed as reply. # size vmlinux.org vmlinux textdata bss dec hex

memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

Try testcase below the sig. This causes nearly one thousand calls to memcpy in my kernel (not an allyesconfig one): # objdump -d vmlinux | grep -F '' | wc -l 959 # gcc -O2 -c t.c # objdump -r -d t.o t.o: file format elf32-i386 Disassembly of section .text: : 0: 55