Re: Char shifts promoted to int. Why?

Chris Lattner wrote: > On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote: >> I seem unable to get a QImode shift instruction from this code: >> >> unsigned char x; >> >> void qishifttest2 (unsigned int c) >> { >>x <<= c; >> } >> >> should have been generated. Also, notice the redunda

Re: Char shifts promoted to int. Why?

> From: Paul Brook <[EMAIL PROTECTED]> > On Monday 18 December 2006 01:15, Paul Schlie wrote: >> Chris Lattner wrote: >>> On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote: >>>> I seem unable to get a QImode shift instruction from this code: >

Re: Char shifts promoted to int. Why?

> Dorit Nuzman wrote: >> Paul Schlie wrote: >> ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) ) :: >> ((char)x) = ((char)( ((char)x) << ((int)c) ) ) >> >> if the shift count ((int)c) is semantically preserved. >> >> thereby con

Re: GCC optimizes integer overflow: bug or feature?

Various folks 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. Now that's a bit TOO

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Richard Guenther wrote: >> Robert Dewar wrote: >>> Daniel Berlin wrote: >>> I'm sure no matter what argument i come up with, you'll just explain it >>> away. The reality is the majority of our users seem to care more about >>> whether they have to write "typename" in front of certain declaration

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Upon attempted careful reading of the standard's excerpts quoted by Gabriel Dos Reis per , it's not clear that GCC's current presumption of LIA-1 overflow semantics in absents of their true support is actually advocated by the standard. As by my rea

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Robert wrote: >> Paul Schlie wrote: >> Upon attempted careful reading of the standard's excerpts quoted by >> Gabriel Dos Reis per <http://gcc.gnu.org/ml/gcc/2006-12/msg00763.html>, >> it's not clear that GCC's current presumption of LIA-1 overfl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Ian Lance Taylor wrote: > ... > I don't personally see that as the question. This code is > undefined, and, therefore, is in some sense not C. If we take > any other attitude, then we will be defining and supporting > a different language. I think that relatively few people want > the language

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Robert Dewar wrote: > ... > I think it is a bad idea for the optimization levels to deal with > anything other than optimization. -fwrapv is not about optimization, > it is about changing the language semantics. > > So this proposal would be tantamount to implementing a different > language at -

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Richard Kenner wrote: > ... > In other words, -fwrapv says that we are modifying the language semantics > to define signed overflows as wrapping and this will have effects on the > optimizer (so the language effect is primary), while -fno-strict-aliasing > says what the optimizer will do and henc

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: > > People always say this, but they don't really realize what they are > saying. This would mean you could not put variables in registers, and > would essentially totally disable optimization. - can you provide an example of a single threaded program where the assignment of

Re: Signed int overflow behavior in the security context

>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >> > Robert Dewar wrote: >> > >> > People always say this, but they don't really realize what they are >> > saying. This would mean you could not put variables in registers, and >

Re: Signed int overflow behavior in the security context

With hind sight, it would appear that as many of these difficulties seem rooted in the historical implicit declaration/conversions of variables/parameters to signed int which has correspondingly tended to be implemented as having wrapping semantics regardless of overflow being undefined; and as typ

Re: Signed int overflow behavior in the security context

> David Daney wrote: >> Paul Schlie wrote: >> (however as you appear to be describing an algorithm attempting to rely on >> the implicit addresses of object storage locations resulting from an assumed >> calling or allocation convention; and as such assumptions are well

Signed int overflow behavior in the security context

> Richard Guenther wrote: > On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote: >>>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >>> Likewise, if the program has an uninitialized variable, the behavior >>> will differ depending on det

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote >> Paul Schlie wrote: >> - However x ^= x :: 0 for example is well defined because absent any >> intervening assignments, all reference to x must semantically yield the >> same value, regardless of what that value may be. > > Nope, th

Re: Signed int overflow behavior in the security context

> Brooks Moses wrote: > ... > Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what ever value may resu

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: >> Paul Schlie wrote: >>> Brooks Moses wrote: >>> <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined

Re: Signed int overflow behavior in the security context

> Paul Schlie wrote: >>> Brooks Moses wrote: >>> <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the con

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> if it has an indeterminate value [...] has no bearing on an rvalue >> access to a well defined storage location > > You might think so, but that's actually not true in the C standard's > terminology. It sounds

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap) > > Can you cite the part of the standard that says that? The fact that > an expression designates an object does not exclud

Re: Signed int overflow behavior in the security context

> Joseph Myers wrote: > DR#260 seems clear enough that indeterminate values may be treated > distinctly from determinate values including randomly changing at any > time. One can only hope that the recommendations won't see the light of

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> One can only hope that the recommendations won't see the light of day in >> their present form, as it's fairly clear that once an unspecified value is >> read (presuming absents of a trap representation), it beco

Re: Signed into overflow behavior in the security context

> Robert wrote: >> Paul Schlie wrote: >> - agreed, and thereby objects having no legitimate trap representation, >> such as most if not all implementations of integers and floating point >> objects on most if not all current target machines, and thereby their >> ac

Re: Signed into overflow behavior in the security context

> Paul wrote >> Robert wrote: >>> Paul Schlie wrote: >>> - agreed, and thereby objects having no legitimate trap representation, >>> such as most if not all implementations of integers and floating point >>> objects on most if not all current target ma

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> is required to be well specified [...] as otherwise the language >> couldn't be utilized to write even the most hardware drivers >> required of all computer systems. > > In a sense, the language *can't* be used

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

> Zack Weinberg > The target macros described in the "Addressing Modes" section of the > internals manual are rather badly in need of cleaning up. I see three > primary reasons why this is so: - Very Nice; and wonder, although somewhat orthogonal, if it would be similarly desirable to clean up

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

ram memory space, to efficiently access such data without needing to copy it in bulk to the machines typically sparse data memory for use; would be very helpful for such targets. (as it's not clear how this may be done presently?) > From: Paul Schlie <[EMAIL PROTECTED]> >

Re: Different sized data and code pointers

> Thomas Gill wrote: > I'm working on a GCC backend for a small embedded processor. We've got a > Harvard architecture with 16 bit data addresses and 24 bit code > addresses. How well does GCC support having different sized pointers for > this sort of thing? The macros POINTER_SIZE and Pmode seem t

Re: Extension compatibility policy

> Joseph S. Myers writes: > How about calling decl_attributes from fname_decl so a target > insert_attributes hook can add attributes to __func__? Would that suffice > to solve your problem? Might it be possible to alternatively add an attribute symbol hook so that a target may easily define an a

Re: Extension compatibility policy

> From: "Joseph S. Myers" <[EMAIL PROTECTED]> >> On Tue, 1 Mar 2005, Paul Schlie wrote: >> Might it be possible to alternatively add an attribute symbol hook so that a >> target may easily define an arbitrary target specific named attribute which >>

Re: Extension compatibility policy

> From: "Joseph S. Myers" <[EMAIL PROTECTED]> >> - and used following the above referenced ""Attribute Syntax", as >> either a variable, or function parameter declaration/implementation: >> >> int ROM x = 3; >> >> int foo (int ROM y) >> >> where the parameter's attribute is

Re: Extension compatibility policy

> From: "E. Weddington" <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> More specifically, there seem to be two predominant motivating reasons >> why it may be desired to attach a target specified attributes to compiler >> generated static constant objects

Re: Different sized data and code pointers

>>>> Paul Schlie wrote: >>>> If the program's address space pointer is more accurately implemented >>>> as a 16-bit pointer combined with an 8-bit segment address; wonder if >>>> it may be worth your while to take a look at how the old seg

Re: Extension compatibility policy

> Bernardo Innocenti wrote: >> Joseph S. Myers wrote: >>> On Wed, 2 Mar 2005, Bernardo Innocenti wrote: >>> To move strings into program memory, there's a macro like this: >>> >>> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; }) >>> >>> But this wouldn't work because __func__ d

Re: Target specific memory attributes from RTL

(I and likely others would also be grateful for further insight) As to enable the efficient use of non-Von-Newman memory architectures typical of many vector/signal processors, and smaller microcontrollers; it seems imperative that target specific attributes assigned to an object remain correct th

Re: Extension compatibility policy

> From: "E. Weddington" <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> After having the chance to experiment a little, it would seem most ideal in >> the short term to enable GCC to add an explicit target specific attribute to >> the effective implied

Re: [OT] __builtin_cpow((0,0),(0,0))

> Ronny Peine > > Maybe i found something: > > http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps > page 9 says: > > "A number of real expressions are sometimes implemented as INVALID > by mistake, or declared Undefined by illconsidered > language standards; a few examples are ... > 0.0**

Re: __builtin_cpow((0,0),(0,0))

> Gabriel Dos Reis wrote: > You probably noticed that in the polynomial expansion, you are using > an integer power -- which everybody agrees on yield 1 at the limit. > > I'm tlaking about 0^0, when you look at the limit of function x^y Out of curiosity, on what basis can one conclude: lim{|x|==

Re: __builtin_cpow((0,0),(0,0))

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> writes: > | > Gabriel Dos Reis wrote: > | > You probably noticed that in the polynomial expansion, you are using > | > an integer power -- which everybody agrees on yield 1 at the

Re: __builtin_cpow((0,0),(0,0))

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> > |Paul Schlie <[EMAIL PROTECTED]> writes: > | Thank you. In essence, I've intentionally defined the question of x^y's > | value about x=y->0 as a constrained "bivariate" function, to where only > | the

Re: __builtin_cpow((0,0),(0,0))

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> writes: > | > From: Gabriel Dos Reis <[EMAIL PROTECTED]> > | > |Paul Schlie <[EMAIL PROTECTED]> writes: > | > | Thank you. In essence, I've intentionally defin

Re: short int and conversions

> I'm trying to port gcc 4.1 for an architecture that has the following > memory layout BITS_PER_UNIT=32 and UNITS_PER_WORD=1. > It has support (16bit registers and operators) for 16bit signed > atithmetic used mainly for addressing. There are also operators for 32 > bit integer and floating point

Re: AVR: CC0 to CCmode conversion

> 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 register and havn't added the > '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the > CC_RE

Re: Suggestion for a fix to Bug middle-end/20177

> Steven Bosscher wrote: >> Mostafa Hagog <[EMAIL PROTECTED]> wrote: >> This is interesting, so there could be cases were want to copy CC >> register when doing SMS. what happens if we want to move the set >> of a CC to another iteration of the loop ? or the use of the CC ? but >> usually this is

Re: AVR: CC0 to CCmode conversion

> From: Denis Chertykov <[EMAIL PROTECTED]> >> 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 becaus

Re: AVR: CC0 to CCmode conversion

> From: Denis Chertykov <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> writes: >>> From: Denis Chertykov <[EMAIL PROTECTED]> >> - although I agree that there's likely a cleaner more consistent way >> to accurately describe and track co

Re: AVR: CC0 to CCmode conversion

Sorry meant denote the setting of FLAG_REGS based solely on it's result, which should be implied by operand 0, the target of 3-operand instructions; with the exception of compare, as it's effective target are the FLAGS_REGS. corrected below: > From: Paul Schlie <[EMAIL PROTECTE

Re: AVR indirect_jump addresses limited to 16 bits

> Marek Michalkiewicz wrote: > I'm looking into adding support for ATmega256x and larger devices to > the AVR port. This means that program memory addresses no longer fit > in 16 bits - and I'm looking how to avoid making pointers larger. - Fully agree, just can't keep from wondering if this may

Re: AVR indirect_jump addresses limited to 16 bits

> From: Paul Schlie <[EMAIL PROTECTED]> >> Marek Michalkiewicz wrote: >> I'm looking into adding support for ATmega256x and larger devices to >> the AVR port. This means that program memory addresses no longer fit >> in 16 bits - and I'm looking how to

Re: AVR: CC0 to CCmode conversion

> From: Björn Haase <[EMAIL PROTECTED]> > I have the impression that you are trying to open open doors :-) : If IIUC > what Denis aims to do is to segment the re-organization of the back-end into > several independent small steps. One step will be the cc0 -> CC_mode issue he > is addressing now. Th

Re: AVR indirect_jump addresses limited to 16 bits

> From: Marek Michalkiewicz <[EMAIL PROTECTED]> >> - Fully agree, just can't keep from wondering if this may be most >> efficiency accomplish by simply requiring the alignment of all >> function entry points to be two instruction word aligned. Thereby > > This only doubles the available addres

Re: AVR indirect_jump addresses limited to 16 bits

> From: Marek Michalkiewicz <[EMAIL PROTECTED]> > Good question - I can't. On the other hand, the manual says: > > `indirect_jump' > An instruction to jump to an address which is operand zero. *This pattern > name is mandatory on all machines.* > > Why would it be mandatory if it was not truly

Re: AVR: CC0 to CCmode conversion

> From: Björn Haase <[EMAIL PROTECTED]> > In my opinion segmenting the rework of the back-end would indeed be the best > approach, also because I expect that the instruction patterns *with* > splitting will be fairly different. E.g. I do not think that the "addsi3" > will be present any more. So it

Re: AVR indirect_jump addresses limited to 16 bits

> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Marek Michalkiewicz <[EMAIL PROTECTED]> >> Good question - I can't. On the other hand, the manual says: >> >> `indirect_jump' >> An instruction to jump to an address which is operand ze

Re: AVR indirect_jump addresses limited to 16 bits

> From: Giovanni Bajo <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> - Sorry, I'm confused; can you give me an example of legal C >> expression specifying an indirect jump to an arbitrary location >> within a function? > It is p

Re: AVR indirect_jump addresses limited to 16 bits

> From: Paul Brook <[EMAIL PROTECTED]> > Don't we know which labels are targets of indirect jumps? > So the proposed restriction now becomes: functions *and targets of indirect > jumps* must be aligned to an N word boundary. I'd guess that the latter are > sufficiently rare that this is still an ac

Re: AVR: CC0 to CCmode conversion

> From: Richard Henderson <[EMAIL PROTECTED]> > 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 for reload. :( As I remember. > > I

Re: AVR: CC0 to CCmode conversion

> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Richard Henderson <[EMAIL PROTECTED]> >> 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

Re: AVR: CC0 to CCmode conversion

> From: Denis Chertykov <[EMAIL PROTECTED]> >> - possibly something like: ? >> >> (define_insn "*addhi3" >> [(set (match_operand:HI 0 ...) >>(plus:HI (match_operand:HI 1 ...) >> (match_operand:HI 2 ...))) >> (set (reg ZCMP_FLAGS) >>(compare:HI (plus:HI (m

Re: AVR indirect_jump addresses limited to 16 bits

> From: Marek Michalkiewicz <[EMAIL PROTECTED]> >> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote: >> The easiest way is to do this in the linker instead of the compiler. >> See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This >> has the distinct advantage that

Re: AVR: CC0 to CCmode conversion

> From: Denis Chertykov <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> writes: >> ... >> (Observing that I'm basically suggesting treating the cc-status register >> like any other hard register, who's value would need to be saved/restored

Re: A plan for eliminating cc0

> Ian Lance Taylor writes: > We would like to eliminate cc0 and the associated machinery from the > compiler, because it is complicated and not supported on popular or > modern processors. Here is a plan which I think could accomplish that > without unreasonable effort. I pre-apologize if this i

Re: A plan for eliminating cc0

> From: Ian Lance Taylor >> Paul Schlie <[EMAIL PROTECTED]> writes: >> Does GCC truley need to identify/treat condition state registers uniquely >> from any other value produced as a result of a calculation? > > No, it doesn't. The change I am prop

Re: A plan for eliminating cc0

> From: Ian Lance Taylor >> Paul Schlie <[EMAIL PROTECTED]> writes: >> Thereby enabling something like: >> >> (insn xxx [(set (reg: A) (xxx: (reg: B) (reg: C))) >>(set (reg: CC) (newly-set-reg: A)) >> ) >

Re: A plan for eliminating cc0

> From: Ian Lance Taylor > I'm also not aware of processors changing as you describe, except for > the particular special case of SIMD vector instructions. gcc can and > does represent vector instructions as a single set. - Understood, unfortunately hiding the multiple-set nature of instructions

Re: A plan for eliminating cc0

> From: Ian Lance Taylor >> Paul Schlie <[EMAIL PROTECTED]> >> (is this not feasible if the target is accurately described in rtl?) > > I don't know how to respond to this. I'm discussing a way to achieve > an incremental improvement in gcc. You seem

Re: A plan for eliminating cc0

Hi Ian, (getting back to reality) upon reviewing things further, it appears that if GCC could relax it's single-set restriction to enable a restricted form of multi-set instructions to be included in optimizations; then ISA's who's instructions either implicitly set or depend on global machine stat

Re: A plan for eliminating cc0

> From: Ian Lance Taylor >> Paul Schlie <[EMAIL PROTECTED]> writes: >> Might this likely work? And if so, possibly be worthy of consideration to >> enable the more efficient description and optimization of traditional cc0 >> target machines (and possibly be b

Re: A plan for eliminating cc0

> From: Paul Koning <[EMAIL PROTECTED]> >> "tm" == tm gccmail <[EMAIL PROTECTED]> writes: >>> On 25 Mar 2005, Ian Lance Taylor wrote: >>> Safe but very costly. It assumes that every processor has a cheap >>> way to save and restore the condition codes in user mode, which is >>> not necessarily the

Re: A plan for eliminating cc0

> Richard Henderson >> Ian Lance Taylor wrote: >> OK, here is a different approach toward eliminating cc0, based on a >> combination of my earlier proposal and what Alex described. I'm >> looking for comments from anybody. > > One potential problem: once the NOTICE_UPDATE_CC pass is done, we > ca

Re: RFC: #pragma optimization level

> Joe Buck wrote: >>Georg Bauhaus <[EMAIL PROTECTED]> writes: >> | A busy-loop function is used to effect a delay, not too precise, >> | but portably. Like >> | >> | #define COUNT 1000 >> | >> | void f() { >> |/*volatile*/ /*register*/ int i; >> | >> |for (i = 0; i < COUNT; ++i) >> |

Re: Use Bohem's GC for compiler proper in 4.1?

> | But I doubt that projects to buy small linear gains in memory usage > | are mainstream very worthwhile in the long run (non-linear gains are > | *always* worth going after by contrast). > > I wasn't aware that people were exclusively concentrating on small > linear gains. although don't know

Re: Obsoleting c4x last minute for 4.0

> Kazu Hirata wrote: > I would like to propose that the c4x port be obsoleted for 4.0. > > c4x-* > tic4x-* > > The primary reason is that the port doesn't build. > > Richard Sandiford's recent patch allows us to go further during the > build process, but the port still does not build. Althoug

Re: Q: C++ FE emitting assignments to global read-only symbols?

>> On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote: >>> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote: Daniel Berlin wrote: Your transform is correct. The FE is not. The variable is not read only. It is write once, then read-only. >>> >>> Diego, your analysis is exact

Re: Q: C++ FE emitting assignments to global read-only symbols?

> Richard Kenner wrote: >>It would be good to have a way to mark things as "write once, then >>readonly" IMO. It's very common, and you can do some of the same >>optimizations on such things that you can do on true Readonly objects. > > We used to do this in RTL and it caused all sorts

Re: Q: C++ FE emitting assignments to global read-only symbols?

> Giovanni Bajo writes: >> Dale Johannesen <[EMAIL PROTECTED]> wrote: >>> I do think the C++ FE needs fixing before Diego's change gets merged, >>> though. I can make the change, but not instantly. If someone files >>> a PR, and assigns to me, I'll get to it at some not-too-distant >>> point. >>

Re: Heads-up: volatile and C++

> Michael N. Moran wrote: > I'm very much in favor of fine grained synchronization primitives > in the compiler, but not of changes to volatile semantics. I wonder if it would be sufficient (if not preferable) to only extend (modify) the semantics for heap/stack and const volatile variables, as en

Re: Heads-up: volatile and C++

> From: Paul Koning <[EMAIL PROTECTED]> >>>>>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: > >>> Michael N. Moran wrote: I'm very much in favor of fine grained >>> synchronization primitives in the compiler, but not of c

[RFC] warning: initialization discards qualifiers from pointer target type

> warning: initialization discards qualifiers from pointer target type > > This warning can not be disabled using -Wno-cast-qual > (or any other warning flags). Is it intentional ? > Otherwise I'll prepare patch. > > const char *a( void ) > { >return "abc"; > } > > int main( void ) > { >

Re: Reload Issue -- I can't believe we haven't hit this before

> Eric Botcazou writes: >> Jeffrey A Law writes: >> ... >> Which faults because the memory location is actually read-only memory. > > PR rtl-optimization/15248. > >> What's not clear to me is how best to fix this. >> >> We could try to delete all assignments to pseudos which are equivalent >> to M

Re: Reload Issue -- I can't believe we haven't hit this before

> From: Paul Schlie <[EMAIL PROTECTED]> > > some-const-char*-funct("abc"); // "C.x[4] = {'a','b','c',0} array >// of "literal static const data" >// some

Re: Reload Issue -- I can't believe we haven't hit this before

> Jeffrey A Law wrote: > ... > But what worries me even more is spilling. Say a pseudo has a hard reg > assigned and is also equivalent to a readonly memory location. Reload > then decides to spill the pseudo out of the hard reg because the hard > reg was needed for something else. When that occ

Re: Reload Issue -- I can't believe we haven't hit this before

Sorry, to be clearer, what I meant by: > From: Paul Schlie <[EMAIL PROTECTED]> > .. (thereby the pseudo is now equated with the spilled value), or ... was: (thereby the pseudo is now equated with an allocated temporary memory location, now storing the spilled value), or ...

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> James E Wilson wrote: > ... > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to stack > slots may not have MEM_EXPR set, but then

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> From: James E Wilson <[EMAIL PROTECTED]> >> - One of the things that's been eluding me, is that I can't seem to find >> where literal string constant mem references aren't being properly >> declared and/or preserved as READONLY/unchanging references, resulting >> in MEM_READONLY_P failing t

Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

> From: James E Wilson <[EMAIL PROTECTED]> >> On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: >> Thanks. After going through the code, it's even further not clear why >> STRING_CST string literal data references treated differently than >> static const char

Re: different address spaces

> From: Zack Weinberg <[EMAIL PROTECTED]> >> James E Wilson <[EMAIL PROTECTED]> writes: >> >>> unnecessary, and error prone (as evidenced by string literal memory >>> references not being properly identified as READONLY, although their >>> equivalent array representations are treated properly

Re: different address spaces

> From: Paul Schlie <[EMAIL PROTECTED]> > ... > (with respect to: -Wwrite-strings, I would have thought that the option, > although presently depreciated and disabled by default, would only have > enabled writes to string literal references be specified at the language &g

Proposal: GCC core changes for different address spaces

> Martin Koegler wrote: > ... > Before I start experimenting with this, I want other people opinions, > how acceptable this proposal will before GCC mainline or if it can be > improved. - sound's good, and a natural generalization of current mem ref attributes. (However ideally, function paramete

Re: Proposal: GCC core changes for different address spaces

> From: Paul Schlie <[EMAIL PROTECTED]> >> Martin Koegler wrote: >> ... >> Before I start experimenting with this, I want other people opinions, >> how acceptable this proposal will before GCC mainline or if it can be >> improved. > > - sound's

Re: Proposal: GCC core changes for different address spaces

> From: Martin Koegler <[EMAIL PROTECTED]> >> On Sat, Apr 23, 2005 at 02:26:54PM -0400, Paul Schlie wrote: >> - sound's good, and a natural generalization of current mem ref attributes. >> >> (However ideally, function parameter and result value references

Re: Proposal: GCC core changes for different address spaces

> Etienne Lorrain <[EMAIL PROTECTED]> wrote: > I see a lot more address space than that in generic processors, not only > embedded systems with EEPROM. - Almost, but they aren't "memory spaces" in the sense that programming languages expect them to be, as they impose implied restrictive semantic

Re: A plan for eliminating cc0

> From: Alexandre Oliva <[EMAIL PROTECTED]> >> On Mar 28, 2005, Paul Schlie <[EMAIL PROTECTED]> wrote: > >> More specifically, if GCC enabled set to optionally specify multiple targets >> for a single rtl source expression, i.e.: > >> (set (

Re: A plan for eliminating cc0

> From: Alexandre Oliva <[EMAIL PROTECTED]> >> On Mar 28, 2005, Paul Schlie <[EMAIL PROTECTED]> wrote: > >> More specifically, if GCC enabled set to optionally specify multiple targets >> for a single rtl source expression, i.e.: > >> (set (

Re: different address spaces

> Martin Koegler wrote: > I have redone the implementation of the eeprom attribute in my prototype. > It is now a cleaner solution, but requires larger changes in the core, > but the changes in the core should not affect any backend/frontend, if > it does not uses them (except a missing case in tre

Re: different address spaces

> From: Martin Koegler <[EMAIL PROTECTED]> >> On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote: >>> Martin Koegler wrote: >>> I have redone the implementation of the eeprom attribute in my prototype. >>> It is now a cleaner solution, but requir

Re: different address spaces

> From: Martin Koegler <[EMAIL PROTECTED]> >> On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote: >>> For the MEM_AREA for the tree, I have eliminated many explicit set operation >>> of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly)

  1   2   3   >