Paranoider Deutschenmoerder kommt in Psychiatrie

Lese selbst: http://brandenburg.rz.fhtw-berlin.de/poetschke.html

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: 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: 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: 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: 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 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 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 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 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: 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: 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

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: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

0.0% 481.wrf -0.6% -0.3% 482.sphinx3 0.0%0.0% SPECfp_base2006 -3.5% -3.5% Denis

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

GDC

Maybe you can add gdc to your GCC front-ends listing (http://home.earthlink.net/~dvdfrdmn/d/).

CC0 to CCmode conversion

_REGNUM just because AVR is'n needed in scheduling. I think that sequence of compare + cond-jump will exists in any compiler pass. The port was successfully tested without new regressions. What do you (MAINTAINERS) think about this ? Denis.

Re: AVR: CC0 to CCmode conversion

Paul Schlie <[EMAIL PROTECTED]> writes: > > Denis wrote: > > I have converted the AVR port from CC0 to CCmode. > > But may be I have converted the port in wrong way. > > (It's because I was interested in *this* way.) > > > > I have used CCmode regi

Re: AVR: CC0 to CCmode conversion

Paul Schlie <[EMAIL PROTECTED]> writes: > > From: Denis Chertykov <[EMAIL PROTECTED]> > >> Paul Schlie <[EMAIL PROTECTED]> writes: > >>> Denis wrote: > >>> I have converted the AVR port from CC0 to CCmode. > >>> But may

Re: CC0 to CCmode conversion

Bernardo Innocenti <[EMAIL PROTECTED]> writes: > Denis Chertykov wrote: > > > I have converted the AVR port from CC0 to CCmode. > > That's indeed very good news. Incidentally, CC0 > conversion of the AVR target was being discussed > in an off-list thread with

Re: AVR: CC0 to CCmode conversion

" "2, ...")]) You have presented a very good example. Are you know any port which already used this technique ? As I remember - addhi3 is a special insn which used by reload. The reload will generate addhi3 and reload will have a problem with two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad surprise for reload. :( As I remember. Denis.

Re: AVR: CC0 to CCmode conversion

Richard Henderson <[EMAIL PROTECTED]> writes: > On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote: > > The reload will generate addhi3 and reload will have a problem with > > two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad > > surprise f

Re: AVR: CC0 to CCmode conversion

Paul Schlie <[EMAIL PROTECTED]> writes: > > From: Denis Chertykov <[EMAIL PROTECTED]> > >> - possibly something like: ? > >> > >> (define_insn "*addhi3" > >> [(set (match_operand:HI 0 ...) > >>(

Re: AVR indirect_jump addresses limited to 16 bits

relocs, used like this: > > .word pm16(label) > > ldi r30,pm16_lo8(label) > ldi r31,pm16_hi8(label) > > and the linker can do the rest of the magic (add jumps in a section > below 64K words if the label is above). > > Cc: to Denis, as I may need help actu

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

[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

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

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: 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 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: [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-m

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: 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: 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". >

[BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

Such an example can't be compiled: #include void x() { printf(__FUNCTION__ "\n"); } $ gcc printf.c -o fprintf printf.c: In function `x': printf.c:5: error: syntax error before string constant Then, the problem is not printf-specific and is not depend of . The next example gives the sam

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

On Mon, Jul 25, 2005 at 10:51:23AM +0200, Richard Guenther wrote: > On 7/25/05, Denis Zaitsev <[EMAIL PROTECTED]> wrote: > > Such an example can't be compiled: > > > > > > #include > > > > void x() > > { > > printf(__F

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

On Mon, Jul 25, 2005 at 11:35:27AM +0200, Paolo Bonzini wrote: > > Ok, but such a code used to be compiled succesively with gcc for > > years. Then, some change _in_ gcc has occured. That is why I've > > posted to here. > > Yes, it was deprecated in 3.1 (released three years ago) and removed in

Re: cross builds to avr fail

newlib/libc/misc/init.c:56 (set > (mem/c:HI (plus:HI (reg/f:HI 28 r28) > (const_int 1 [0x1])) [5 S2 A8]) > (reg:HI 24 r24)) 12 {*movhi} (nil) > (nil)) > ../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal > compiler error: in spill_failure, at reload1.c:1890 Please send a preprocessed init.c Denis.

Re: Register Allocation

, and how? The rable.pdf completely miss description of registers elimination. It's important and difficult part of RA. (The "old new-ra" also havn't eliminatin) Denis.

Re: split_live_ranges_for_shrink_wrap and !SHRINK_WRAPPING_ENABLED?

it when > optimizing for size (using the condition part in simple_return pattern) > - understandable. > > What do you guys think is the right way to deal with this? Should I look > into why range splitting helps reload and have reload itself handle this? It's a place for experiments. Generally, live range splitting must be very useful for targets with constrained register classes and for targets with small amount of registers. Denis.

Re: INSN_CODE used on jump_table_data

2014-04-30 1:29 GMT+04:00 Tom de Vries : > Denis, > > when building gcc for avr with --enable-checking=yes,rtl , I run into the > following error: > ... > /home/vries/gcc_versions/devel/src/libgcc/unwind-c.c: In function > ‘__gcc_personality_sj0’: > /home/vries/gcc_versions

Re: RFA: Add avrtiny support

2014-10-21 21:18 GMT+04:00 Joern Rennecke : > In __do_global_dtors, I ended up changing the order of execution > in order to get back to the forwards/backwards order as found in > crtstuff.c > The patch I attached to target/63223 is actually an extract from this patch. Approved. Denis.

Re: Second GCC 5.1 Release Candidate successful avr target build

ts to repeat it: > https://github.com/nerdralph/nerdralph/tree/master/avr/make-avr-gcc > Thank you for testing and reporting. Denis.

How to force gcc to vectorize the loop with particular vectorization width

-unroll-times is not suitable for me, because it will affect other parts of the code. Is it possible to achieve this somehow? -- Best regards, Denis.

Re: How to force gcc to vectorize the loop with particular vectorization width

mehow achieve this in gcc by tweaking the code or adding some pragma? On 19/10/2017, Jakub Jelinek wrote: > On Thu, Oct 19, 2017 at 10:38:28AM +0200, Richard Biener wrote: >> On Thu, Oct 19, 2017 at 9:22 AM, Denis Bakhvalov >> wrote: >> > Hello! >> > >> >

Re: How to force gcc to vectorize the loop with particular vectorization width

< 16? On 20/10/2017, Richard Biener wrote: > On Fri, Oct 20, 2017 at 12:13 PM, Denis Bakhvalov > wrote: >> Thank you for the reply! >> >> Regarding last part of your message, this is also what clang will do >> when you are passing vf of 4 (with the pragma from

Re: GCC 4.6.0 Status *-rtems

2011/2/7 Joel Sherrill : > > There are two targets which cannot build C -- avr and lm32: > > + avr - http://gcc.gnu.org/PR47534 I have committed the fix r169896 Please somebody close the bug. I can't login to bugzilla. (Probably I forgot my login and password) Denis.

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

t; >>> So the same should be true for QI-subregs of scalar modes if >>> UNITS_PER_WORT = 1. Right? >> >> Right. > > Thanks for that definite clarification. As I understand PR46779 and PR45291 no longer an AVR port bugs. And the following comment is not a true anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45291#c2 Am I right ? Denis.

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

2011/2/26 Georg-Johann Lay : > Georg-Johann Lay schrieb: >> >> Denis Chertykov schrieb: >> >>> 2011/2/26 Georg Johann Lay >>> >>>> Eric Botcazou schrieb: >>>> >>>>>> What does "word" mean here?

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

2011/2/28 Georg-Johann Lay : > Denis Chertykov schrieb: >> >> 2011/2/26 Georg-Johann Lay : >> >>> Ok, this is the patch I meant: >>> >>> http://gcc.gnu.org/viewcvs?view=revision&revision=86842 >>> >>> it allows just Pmod

g++ 4.6 and suggested flags

downloaded gcc 4.6, and tried it. And I found something a little strange when I compile a file : g++ displayboard.cpp -lncurses -c displayboard.cpp: In constructor ‘DisplayBoard::DisplayBoard(int, int)’: displayboard.cpp:47:22: error: invalid conversion from ‘void (* (*)())(int)’ to ‘sighandler_t

Re: Using secondary reload to reload CONST_INT?

uot;) (set (match_operand:SI 0 "l_register_operand" "") (match_operand:SI 1 "immediate_operand" "")) (match_dup 2)] "(operands[1] != const0_rtx && operands[1] != constm1_rtx)" [(parallel [(set (match_dup 0) (match_dup 1)) (clobber (match_dup 2))])] "") > > The drawback is that this allocates 4 GPRs (AVR is 8-bit machine). Please, provide an example. Denis.

Re: Using secondary reload to reload CONST_INT?

2011/3/21 Georg-Johann Lay : > Denis Chertykov schrieb: >> 2011/3/20 Georg-Johann Lay : >>> The AVR controller basically has two kinds of hard registers: >>> >>> * LD_REGS (constraint "d") that can move immediates >>> * NO_LD_REGS (constraint

Re: IRA/reload make bulky code: why stack slots where GPR is fine?

sable-shared > Thread model: single > gcc version 4.7.0 20110404 (experimental) (GCC) GCC 4.6 produces right code. b: /* prologue: function */ /* frame size = 0 */ /* stack size = 0 */ .L__stack_usage = 0 rcall a adiw r24,1 /* epilogue start */ ret Denis.

Re: Improve addsi3 for CONST_INT

2011/7/8 Georg-Johann Lay : > Denis Chertykov wrote: >> 2011/7/7 Georg-Johann Lay: >>> Hi Denis. >> >> I think that it's a good question to discuss inside gcc mailing list. >> May be somebody more qualified person give a better suggestion than me. >

Re: FDO and LTO on ARM

fy >> that I try some more with current GCC HEAD? Should I maybe try some more >> with the linaro GCC branch? Are there things we can do to help getting >> better ARM performance? > > It does not hurt to try it :) > Linaro android toolchain benchmarks: https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07 Denis.

Re: [Patch,AVR]: Better log output with -mdeb

vr__set_caller_f): New functions. > > Sorry, picked the wrong ML. > I have no objections against the patch. May be better to put it in separate file. (avr-debug.c or avr-log.c) Denis.

Re: Help: Register allocator sets up frame at low register pressure (PR 50775)

ollowing array. */ int num_objects; /* An array of structures describing conflict information and live ranges for each object associated with the allocno. There may be more than one such object in cases where the allocno represents a multi-word register. */ ira_object_t objects[2]; --^ The SImode for AVR consists of 4 words, but only 2 objects in allocno structure. Is this right ? Denis.

Re: [Patch,AVR] Was/Fix: error linking lto1 for target avr

with --enable-plugin. > > Maybe the patch can be pre-approved so that the others can proceed with their > work? Better to complete this work. Denis.

Re: GCC 4.7 Status Report for *-rtems

intainers can look at this PR ? (Ulrich Weigand, Bernd Schmidt) Denis.

Error when building cross compiler

I am getting the following error when compiling "x86_64 to powerpc64" cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc directory. ... # Now that we have built all the objects, we need to copy # them back to the GCC directory.  Too many things (other # in-tree libraries, and DejaGNU

Re: Error when building cross compiler

>> There is something peculiar going on, because a >> x86_64-unknown-linux-gnu hosted compiler would not normally refer to >> libgcc_s.so.1 at all. Even if it did, nothing would normally direct >> the dynamic linker to look in the gcc build directory. Something is >> wrong but I don't know what i

Re: Error when building cross compiler

The error is also reproduced with gcc 4.5 revision 153504

incorrect place for LTO options description

description of the LTO specific options (--enable-lto, --with-libelf and --enable gold) should be placed in "Options specification" section instead of "Java-Specific Options" section on http://gcc.gnu.org/install/configure.html

Re: AVR gives weird error with LTO

2009/12/31 Weddington, Eric : > > >> -Original Message- >> From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net] >> Sent: Wednesday, December 30, 2009 4:34 PM >> To: Richard Guenther >> Cc: Dave Korn; Rafael Espindola; GCC Development; Weddington,

Re: [avr]: potential runtime bug in insn andsi3?

contain the MSB of the result. > > I did not try to find a source that produces a bug basing on that, > but obviously the insn does not do what it states algebraically. > > Besides that, andhi3 says cc=clobber in the similar case "d,0,i", > which is correct IMHO. Thank you. Will be fixed tomorrow. Denis.

Re: having trouble with define_split

ure what I'm doing wrong, > but I don't have a good reference example for this. I can implement > these routines in a library, that might end up being better in terms > of space, but I would like to know what I am doing wrong and how to > use define_split correctly. May be better to define expand like this: (define_expand "fractqqsf2" [(set (match_dup 2) (fract_convert:SA (match_operand:QQ 1 "register_operand" ""))) (set (match_operand:SF 0 "register_operand" "") (fract_convert:SF (match_dup 2)))] "" " operands[2] = gen_reg_rtx (SAmode); ") Denis.

Re: IRA conflict graph & alternative selection

#x27;s constraints.) Because of that idea I have realised pre-relod in new-ra. (I'm agree that pre-reload is an ugly pieces of code) Even more, today I have a set of experiments with pre-reload pass before IRA. I have founded that IRA costs calculation process work better if I have a right insn's before IRA. Denis.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

> arm, 6 bits for m68k). > > This information is particularly important for targets that do not > have a simulator in src. AVR don't have a hardware instructions for variable shifts. While AVR port emulate such shifts the 8bits register used for shift count. AVR port truncate shift counter to 8 bits. Denis.

GCC 4.5: "nonconstant array index in initializer" error

The following errors appears when I tried to compile linux kernel 2.6.30-rc2 with GCC 4.5: linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index in initializer linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization for 'drm_ioctls') ... compiled code looks like this

Re: GCC 4.5: "nonconstant array index in initializer" error

integer constant expression 2009/4/23 Joseph S. Myers : > On Thu, 23 Apr 2009, Denis Onischenko wrote: > >> The following errors appears when I tried to compile linux kernel >> 2.6.30-rc2 with GCC 4.5: >> >> >> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstan

Re: GCC 4.5: "nonconstant array index in initializer" error

4.5.0 revision 146607 compiles this code with following errors: test.c:5: error: nonconstant array index in initializer test.c:5: error: (near initialization for 'arr') released GCC 4.4.0 compiles without any errors 2009/4/23 Joseph S. Myers : > On Thu, 23 Apr 2009, Denis Oni

Re: GCC 4.5: "nonconstant array index in initializer" error

) : __invalid_size_argument ) enum { ENUM_VALUE_NAME = TYPECHECK(int), }; int main() { return 0; } The error is following: test.c:5: error: enumerator value for 'ENUM_VALUE_NAME' is not an integer constant GCC 4.4.0 compiles this code without any error. 2009/4/24 Joseph S. Myers : > On Thu, 23 Ap

Re: GCC 4.5: "nonconstant array index in initializer" error

> Is the kernel using this sort of non-integer-constant-expression in > bit-field widths as well?  Sizes of file-scope arrays (OK, a special case > for that was added for WINE)?  Null pointer constants (that's much more > problematic to add special cases for)?  __builtin_choose_expr conditions? > I

relative include search path

I have a problem with gcc not finding location for stddef.h include file when it is invoked from directory other than /bin. Output from gcc invocation with -v option contains the following: ignoring nonexistent directory "../lib/gcc..." i.e. gcc is trying to find include files in directory with r

Re: AVR C++ - how to move vtables into FLASH memory

the .rodata section which > holds read-only data.  All you should need to do it arrange for the > .rodata section to be placed in FLASH rather than SRAM.  This would > normally be done in your linker script. No, no. movMODE insns for AVR don't support FLASH (PROGMEM), only SRAM. Denis.

Re: Reload problems with only one base reg for "base + offset" addressing mode

ill can't > work. > > Do I miss some "macro" definition? > > Could someone give some direction? I have a lot of experiments with reloading memory addresses while I debug AVR port. Finally I have emulated memory addressing with infinite displacement. Look carefully at avr.c: out_movhi_r_mr Denis.

Re: Reload problems with only one base reg for "base + offset" addressing mode

2010/8/1 redriver jiang : > Hi Denis, > > I read the "out_movqi_r_mr" code of the AVR port. I see that following > exception are > > handled: > > 1. "REG_X+offset", which is not supported by AVR. > 2. "REGY+offset", with offset larger tha

Re: Contributing to GCC (for avr target).

tches. > If for incorporate contributions in gcc it is required to sign > copyright assignment, I would like them to sign. Yes, you must sign copyright assignment first. Denis.

CAN_ELIMINATE question

Hi All. While I have debugging AVR target bug I found that something wrong in port code or in reload. Is it right to use of get_frame_size() inside CAN_ELIMINATE macro valid ? If yes then reload have a bug. If no then AVR and probably MIPS ports have invalid definitions of CAN_ELIMINATE. Denis.

Re: CAN_ELIMINATE question

Eric Christopher <[EMAIL PROTECTED]> writes: > On Feb 13, 2006, at 7:43 AM, Denis Chertykov wrote: > > > Hi All. > > > > While I have debugging AVR target bug I found that something wrong in > > port code or in reload. > > > > Is it right to us

Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program

n you comment new patch version. It isn't fully tested but am I going in right direction? 2006-02-13 Denis Nagorny <[EMAIL PROTECTED]> PR rtl-optimization/25603 * reload.c (reg_inc_found_and_valid_p): New. Check REG_INC note. (regno_clobbered_p): Use it. Reusi

Re: CAN_ELIMINATE question

need in call to update_eliminables() somewhere between setup_save_areas() and calculate_needs_all_insns() (Not "about 15 lines after" ;) because all bad things happened inside calculate_needs_all_insns(). calculate_needs_all_insns() collect wrong reloads because reg_eliminate structure for FP->SP have wrong can_eliminate field. Denis.

Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program

James E Wilson wrote: Yes, that is what I was suggesting. It's corrected and tested on ia64 and x86-64. I've attached new version. Denis. Index: reload.c === *** reload.c(revision 35) --- reload.c(wo

Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program

preprocessor too. I feared to overburden code by preprocessor expressions. What is you opinion? Denis.

Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program

. -- Pinski I'll do it. Denis

Re: CAN_ELIMINATE question

Ian Lance Taylor writes: > Denis Chertykov <[EMAIL PROTECTED]> writes: > > > > > I think that better to call update_eliminables() somewhere after > > > > setup_save_areas() > > > > > > Exactly. We do that. About 15 lines after the lines

Re: CAN_ELIMINATE question

Denis Chertykov <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > > Denis Chertykov <[EMAIL PROTECTED]> writes: > > > > > > > I think that better to call update_eliminables() somewhere after > > > > > setup_save_areas() >

AVR port have a problem with reload

Hi Ulrich. Few months ago I has analyzed PR19636 (avr specific bug) and found that it's a reload related problem. I has started the thread http://gcc.gnu.org/ml/gcc/2006-02/msg00213.html but nobody commented the problem. Can you comment the problem as reload maintainer ? Denis.

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

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

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

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

[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: 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); >

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: [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: [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()

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

  1   2   >