Gcc silently transforms a finite loop to an infinite one

Hello, members of GCC development team! I am involved in support of customers who use GCC. Recently a customer has complaint that gcc-4.1.2 generates an infinite loop for the following program: #include extern void f (int); int main () { char e = 0; do { printf ("--- e

Re: Gcc silently transforms a finite loop to an infinite one

Hi, please use gcc-help@ for this type of questions. On Tue, 29 Nov 2011, Nadezhda Ivanоvna Vyukova wrote: > I've explained the customer that by default char is treated > as signed char on our platform and therefore this program > does not conform ISO C90, as it causes the integer overflow > (u

Re: Gcc silently transforms a finite loop to an infinite one

On 11/29/2011 8:29 AM, Michael Matz wrote: IMHO it would be better to issue a warning when a finite loop is transformed to an infinite one (as a result of -ftree-vrp). -Wstrict-overflow gives a warning in this program. This warning isn't active by default. 4.1 didn't yet have this warning II

Re: Gcc silently transforms a finite loop to an infinite one

Nadezhda Ivanоvna Vyukova writes: > I am involved in support of customers who use GCC. > Recently a customer has complaint that gcc-4.1.2 > generates an infinite loop for the following program: > > #include > extern void f (int); > int main () > { > char e = 0; > do > { >

Re: Gcc silently transforms a finite loop to an infinite one

On 29/11/2011 15:25, Ian Lance Taylor wrote: Nadezhda Ivanоvna Vyukova writes: I am involved in support of customers who use GCC. Recently a customer has complaint that gcc-4.1.2 generates an infinite loop for the following program: #include extern void f (int); int main () { c

Re: Gcc silently transforms a finite loop to an infinite one

Hi, On Tue, 29 Nov 2011, Robert Dewar wrote: > > > IMHO it would be better to issue a warning when a finite loop is > > > transformed to an infinite one (as a result of -ftree-vrp). > > > > -Wstrict-overflow gives a warning in this program. This warning isn't > > active by default. 4.1 didn't

Re: Gcc silently transforms a finite loop to an infinite one

On Tue, 29 Nov 2011, Nadezhda Ivan?vna Vyukova wrote: > I've explained the customer that by default char is treated > as signed char on our platform and therefore this program > does not conform ISO C90, as it causes the integer overflow > (undefined behavior). But he was not satisfied. Actually

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

Ian Lance Taylor wrote: > Georg-Johann Lay writes: > >> So if a frontend can define address spaces and it is a generic feature, the >> question is how to get the name of an address space in a generic, language >> independent way. > > We could decide that all frontends that use address spaces mus

Preserve labels for the life of Compliation

Hello Everyone, I would like to insert labels at certain instances of the program as a marker and then print them out at a separate section at the end of the assembly file. I am able to do that but the garbage collector seem to be deleting the labels. Is it possible for me to stop this?

volatile correctness: combine vs. target.md

Hi, I have a question concerning the following C code typedef unsigned char uint8_t; #define SEARCHING (-2) #define UCSR0A (*(volatile uint8_t *)((0x0B) + 0x20)) #define UDR0 (*(volatile uint8_t *)((0x0C) + 0x20)) void __vector_18(void) { unsigned char status = UCSR0A; unsigned char data

Re: volatile correctness: combine vs. target.md

Georg-Johann Lay writes: > Is insn combine allowed to match the insn because from combine's > perspective just a CONST_INT (i.e. low_io_address_operand) is moved > across the access of UDR0? Yes. > Or is this a bug in insn combine? No. > If combine is right -- and thus the pattern is wrong --

Bluna.tv Reel 2012

Hi there! Bluna is a Buenos Aires based motion design studio, and we would love to have the chance to work with you on your next project! Here www.bluna.tv you can see our last reel and some of our last projects. I hope you like them, best! PAto Patricio H. Yamus p...@bluna.tv +5411 3965 3

ANN: gcc-python-plugin 0.7

gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the CPython interpreter within GCC, allowing you to write new compiler warnings in Python, generate code visualizations, etc. It ships with "cpychecker", which implements static analysis passes for GCC aimed at finding bugs in CPython

Re: Gcc silently transforms a finite loop to an infinite one

On 29/11/11 16:44, Joseph S. Myers wrote: On Tue, 29 Nov 2011, Nadezhda Ivan�vna Vyukova wrote: I've explained the customer that by default char is treated as signed char on our platform and therefore this program does not conform ISO C90, as it causes the integer overflow (undefined behavior).

gcc-4.4-20111129 is now available

Snapshot gcc-4.4-2029 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-2029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Gcc silently transforms a finite loop to an infinite one

On Tue, 29 Nov 2011, David Brown wrote: > On 29/11/11 16:44, Joseph S. Myers wrote: > > converting the int to char (which GCC defines as modulo) applies. See PR > > 35634 which has various discussion of possible approaches for fixing > > this, and patches that introduce vectorizer optimization re

A new stack protector option?

Hi, I propose to add to gcc a new option regarding stack protector - "-fstack-protector-strong", in addition to current gcc's "-fstack-protector-all", which protects ALL functions, and "-fstack-protector", which protects functions that have a big (signed/unsigned) char array or have alloca called.

Re: A new stack protector option?

On Wed, Nov 30, 2011 at 7:53 AM, Han Shen(沈涵) wrote: > Hi, I propose to add to gcc a new option regarding stack protector - > "-fstack-protector-strong", in addition to current gcc's > "-fstack-protector-all", which protects ALL functions, and > "-fstack-protector", which protects functions that h

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

2011/11/29 Georg-Johann Lay : > Ian Lance Taylor wrote: >> Georg-Johann Lay writes: >> >>> So if a frontend can define address spaces and it is a generic feature, the >>> question is how to get the name of an address space in a generic, language >>> independent way. >> >> We could decide that all