--- Comment #7 from schlie at comcast dot net 2007-11-16 02:35 ---
Subject: Re: Initializing string literal data
improperly marked frame-relative?, should be readonly static const.
I believe so.
> From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[
--- Comment #9 from schlie at comcast dot net 2007-11-16 02:35 ---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
submitted, a long while ago; but honestly haven't been tracking things
lately.
> From: manu at gcc dot gnu do
--- Comment #18 from schlie at comcast dot net 2007-02-07 00:56 ---
Subject: Re: C++ FE emitting assignments to read-only
global symbols
for 4.3?
> From: rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 5 Feb 200
--- Comment #8 from schlie at comcast dot net 2007-01-06 15:04 ---
It seems that an overflow warning should be generated if an overflowed value
is utilized or results from an expression evaluation between sequence ponts?
Thereby:
x = INT_MAX + 2 - 2 ; // warning x may overflow.
z = (y
--- Comment #8 from schlie at comcast dot net 2005-10-26 10:33 ---
Subject: Re: BLK ptr's losing original ptr's
static-constant readonly attribute.
> --- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-25 19:22
> (In reply to comment #6)
>> - F
--- Additional Comments From schlie at comcast dot net 2005-07-28 21:25
---
(In reply to comment #0)
- just for the record, it appears that the bug is that when a function is
inlined using a built-in, a volatile parameter should be accessed only
once and placed into a temporary
--- Additional Comments From schlie at comcast dot net 2005-07-27 16:22
---
(In reply to comment #4)
> Oh, I agree completely that making string literals const
> (as they are in C++) would make more sense. The reason they
> aren't defined that way in C is that by the ti
--- Additional Comments From schlie at comcast dot net 2005-07-26 23:58
---
(In reply to comment #2)
> String literals in C are char*, not const char*, though writing to a
> string literal invokes undefined behavior. But that's not the point.
Actually as string literals are
--- Additional Comments From schlie at comcast dot net 2005-07-20 19:03
---
(In reply to comment #5)
> (In reply to comment #4)
> > hmm, i think someone should reopen this bug.
> > 4.1 is a good place for major changes in c++ front-end ;)
> Not any more since we are
--- Additional Comments From schlie at comcast dot net 2005-07-20 18:57
---
(In reply to comment #1)
>
> *** This bug has been marked as a duplicate of 4131 ***
Please correct me if I misunderstand, but it doen't seem reasonable to
close this bug as won't fix, b
--- Additional Comments From schlie at comcast dot net 2005-07-03 17:33
---
(In reply to comment #10)
> Hey, we should be *happy* that we found a standard-compliance excluse to fix
> the
> code-breaking regression and make those casts work like everybody wanted!
- I coul
--- Additional Comments From schlie at comcast dot net 2005-07-03 07:54
---
(In reply to comment #39)
> Subject: Re: gcc -O2 discards cast to volatile
So unfortunately, again the question which comes to mind is what
should happen when a program specifies an undefined behav
--- Additional Comments From schlie at comcast dot net 2005-07-03 07:09
---
(In reply to comment #35)
> Subject: Re: gcc -O2 discards cast to volatile
I apologize for interjecting, but wanted to verify my perception the
conclusions reached; are they essentially?:
- although an obj
--- Additional Comments From schlie at comcast dot net 2005-06-27 18:00
---
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add
> two positive numbers and
> have a result that
--- Additional Comments From schlie at comcast dot net 2005-06-26 15:06
---
(In reply to comment #7)
> (In reply to comment #6)
> > The problem here is that gcc is using a DImode register to handle 6 byte
> > (int+long) structure. Why I have no idea!
> This is so it
--- Additional Comments From schlie at comcast dot net 2005-06-20 02:44
---
Subject: Re: 4.1 make install fails trying to install
ungenerated fixproto & fix-header dirs.
please mark as apparently fixed, the problem no longer seems to exist.
> From: pinskia at gcc dot gnu
--- Additional Comments From schlie at comcast dot net 2005-06-13 14:12
---
(In reply to comment #6)
> Changing the expression for accessing the volatile member
> of the struct to:
> "(volatile int)ptr->b;"
> or just:
> "ptr->b;"
> st
--- Additional Comments From schlie at comcast dot net 2005-06-13 11:17
---
(In reply to comment #0)
> I think that the C standard says C that the "name" of variable
> becomes an rvalue (the actual value) thus requires that the variable
> is accessed.
It actually
--- Additional Comments From schlie at comcast dot net 2005-05-21 23:31
---
(In reply to comment #8)
> Subject: Re: wrong-code with inlining and type-punned pointer
> > - Then what is the purpose of the this portion of the standard, if
> >not to clarify the inte
--- Additional Comments From schlie at comcast dot net 2005-05-21 22:28
---
(In reply to comment #6)
> Subject: Re: wrong-code with inlining and type-punned pointer
>
> Sorry, I don't see that implication. However, GCC already has a
> switch for tuning off such co
--- Additional Comments From schlie at comcast dot net 2005-05-21 21:28
---
(In reply to comment #4)
> Subject: Re: wrong-code with inlining and type-punned pointer
> Because this is what the standard says is allowed. The standard also
> says the comparisons and assignmen
--- Additional Comments From schlie at comcast dot net 2005-05-21 20:48
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > This is undefined, see the full discussion on the gcc list:
> > > http://gcc.gnu.org/m
--- Additional Comments From schlie at comcast dot net 2005-05-21 17:31
---
(In reply to comment #1)
> This is undefined, see the full discussion on the gcc list:
> http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
- out of curiosity, it's not clear that the discussion
--- Additional Comments From schlie at comcast dot net 2005-05-19 03:55
---
(In reply to comment #0)
> The current -fdelete_null_pointer_checks implementation makes assumptions that
> the target processor will trap on reads or writes to address zero.
> Unfortunately
--- Additional Comments From schlie at comcast dot net 2005-05-17 21:24
---
(In reply to comment #10)
> (In reply to comment #8)
> > - yes, however as the loigical extention of:
> >"a null reference is undefined" => "may trap" => "
--- Additional Comments From schlie at comcast dot net 2005-05-16 13:25
---
(In reply to comment #9)
Subject: Re: static_cast falsely allows const to be cast away
> Gabriel Dos Reis writes:
>| --- Additional Comments From schlie at comcast dot net 2005-05-16
>| (In
--- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
---
(In reply to comment #7)
> Subject: Re: static_cast falsely allows const to be cast away
> That is your view. However, not because GCC implements the ISO C++
> view of types, means that GCC has a na
--- Additional Comments From schlie at comcast dot net 2005-05-16 02:44
---
(In reply to comment #5)
> Subject: Re: static_cast falsely allows const to be cast away
> | > Yup, string literal should have type 'const char *'.
> |
> | I believe 'static
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:50
---
(In reply to comment #1)
> With -Wwrite-strings, I do get a warning:
> t.cc:3: warning: deprecated conversion from string constant to �char*�'
- arguably, this warning should always be on, and only
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:45
---
(In reply to comment #2)
> Yup, string literal should have type 'const char *'.
I believe 'static const char []' would seem most correct?
(where although 'static const' may b
--- Additional Comments From schlie at comcast dot net 2005-05-10 08:31
---
(In reply to comment #5)
> see comment #1 ...
>
> you already derefenced the pointer in ppv (in the line
> unsigned long lv = *lvp;
> )
>
> so the compiler assumes that anohter
--- Additional Comments From schlie at comcast dot net 2005-05-09 23:19
---
(In reply to comment #1)
> I don't think this is a bug since conf and ppv cannot be null as you
> deferenced them already
> and would trap on most machines. (there is another bug about this rec
--- Additional Comments From schlie at comcast dot net 2005-05-07 05:12
---
(In reply to comment #17)
> I've extended Steven's patch to handle nested aggregates
> (i.e. any combination of ARRAY_REF and COMPONENT_REF).
Does it also work with terminating static const char
--- Additional Comments From schlie at comcast dot net 2005-05-05 17:19
---
(In reply to comment #2)
> "unsigned char *" and "char *" are in two different aliasing sets while char
> and unsigned char are in the same one, well char is every aliasing set.
Then
--- Additional Comments From schlie at comcast dot net 2005-05-01 17:53
---
(In reply to comment #6)
> I have a fix which I am testing. One change to fold_binary to fold "bool_var
> != 0" to bool_var and
> one to fold_widened_comparison to treat BOOLEAN_TYP
--- Additional Comments From schlie at comcast dot net 2005-04-26 14:38
---
(In reply to comment #6)
>> But collate<_CharT>::do_hash() already depends on sizeof(long)..
> ... which, of course, tracks size_t, on every platform I know. Or you have a
> counterexample?
J
--- Additional Comments From schlie at comcast dot net 2005-04-22 18:01
---
(In reply to comment #15)
> Subject: Bug 20973
> Branch: gcc-4_0-branch
> Changes by: [EMAIL PROTECTED]2005-04-22 17:30:21
> Modified files:
> gcc: ChangeLo
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:36
---
(In reply to comment #11)
I believe the optimization necessitates the variable's declaration be changed
(either explicitly, or by implication):
static const double b = a+1.0; => const double b = a+
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:29
---
(In reply to comment #3)
> Simple code which shows we now have a missed optimization:
> static const double a = 1.0;
> static const double b = a+1.0;
>
> double c()
> {
> return b;
>
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:41
---
Subject: Re: Initializing string literal data
improperly marked frame-relative?, should be readonly static const.
> From: Paul Schlie <[EMAIL PROTECTED]>
> Subject: Re: [Bug middle-end/21018]
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:22
---
Subject: Re: Initializing string literal data
improperly marked frame-relative?, should be readonly static const.
> Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr
> sho
--- Additional Comments From schlie at comcast dot net 2005-04-14 21:28
---
(In reply to comment #0)
I guess I misunderstand the problem, as given:
const double ggPi = 3.14159265358979323846;
double const divPi = 1 / ggPi;
It would seem that neither ggPi or divPI should be
--- Additional Comments From schlie at comcast dot net 2005-04-14 07:43
---
(In reply to comment #0)
> resulting tree/rtl:
>
> showing frame-relative reference to "abcde" initializing data which is wrong:
>
> (insn 12 11 13 1 (set (reg:HI 44)
>
--
What|Removed |Added
Summary| initilizing string litteral|Initializing string literal
|data improperly maked frame-|data improperly marked
-1 (nil)
(nil))
showing readonly reference to {'a','b','c','d','e') initializing data which is
correct:
(insn 23 36 24 3 (set (reg:QI 42 [ v.0 ])
(mem/v/i:QI (symbol_ref:HI ("v") ) [0 v+0 S1
A8])) -1 (nil)
(nil))
--
--- Additional Comments From schlie at comcast dot net 2005-04-12 12:45
---
(In reply to comment #0)
As heads up, I've verified this is a target problem, the block mem-move
expansion needs
to treat the expansion differently if the source is a READONLY. This only
leaves three i
--- Additional Comments From schlie at comcast dot net 2005-04-12 09:16
---
Created an attachment (id=8609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8609&action=view)
final resulting code showing all problems.
(including possibly one with stabs source code line corr
--
What|Removed |Added
Attachment #8608|showing problem expanding |showing problem expanding
description|access to blk move structure|access to blk move structure
--- Additional Comments From schlie at comcast dot net 2005-04-12 09:11
---
Created an attachment (id=8608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8608&action=view)
showing problem expanding access to blk move structure move.
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From schlie at comcast dot net 2005-04-12 08:44
---
Created an attachment (id=8606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8606&action=view)
showing "char" function return types being incorrectly converted to "int"
--
--- Additional Comments From schlie at comcast dot net 2005-04-12 08:31
---
Created an attachment (id=8605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8605&action=view)
simplied test case showing "static const" blk mode and function bugs.
--
http://gcc
--- Additional Comments From schlie at comcast dot net 2005-04-12 08:27
---
Created an attachment (id=8603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8603&action=view)
refined patch to config/avr.c required to demonstrate bug.
--
http://gcc.gnu.org/bugzilla/show_
//++
+fatal_insn ("write readonly insn:",insn); //++
if (!l)
l = &tmp;
--
Summary: BLK ptr's loosing original ptr's static-constant
readonly attribute.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc-apple-darwin
GCC host triplet: ppc-apple-darwin
GCC target triplet: avr-none-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
--- Additional Comments From schlie at comcast dot net 2005-03-29 03:42
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
> Static debug data should be based on it's required encoding specification,
> and have nothing to do
--- Additional Comments From schlie at comcast dot net 2005-03-29 02:09
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
>> Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
>> (I think it is defin
--- Additional Comments From schlie at comcast dot net 2005-03-29 01:14
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
> Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
> (I think it is defined by
--- Additional Comments From schlie at comcast dot net 2005-03-29 00:28
---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
> Note all patches should always goto gcc-patches
ok, just sent.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Additional Comments From schlie at comcast dot net 2005-03-28 23:52
---
Created an attachment (id=8476)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8476&action=view)
proposed patch
The following patch enables small targets which don't support a 64 bit
long
erity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
fixproto & fix-header dirs.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
--- Additional Comments From schlie at comcast dot net 2005-03-14 14:25
---
Subject: Re: [4.0/4.1 Regression] libgcc2.h
Improperly determines required built-in function size requirements.
> --- Additional Comments From giovannibajo at libero dot it 2005-03-13
> Closing as
--- Additional Comments From schlie at comcast dot net 2005-03-13 04:17
---
(In reply to comment #25)
> Subject: Re: unable to find a register to spill in class
> `POINTER_REGS'
> ...
> GCC does not need this backend define or expand. It is quite happy
> working
--- Additional Comments From schlie at comcast dot net 2005-03-13 03:39
---
(In reply to comment #23)
> This is a define EXPAND. predicates (such as const_int_operand) and
> pattern have no effect at all on generated code or matching. This
> pattern always emits DON
--- Additional Comments From schlie at comcast dot net 2005-03-13 02:06
---
(In reply to comment #20)
with reference to the most recent patch:
- anding with 0x may turn negatives positive so it seems wrong.
- there's no need limit byte counts to below 0x100 for bytes, as 0xFF
--- Additional Comments From schlie at comcast dot net 2005-03-07 17:30
---
Subject: Re: MEM_READONLY_P & MEM_VOLATILE_P
properties are lost on BLKmode rtl operands.
> - Additional Comments From giovannibajo at libero dot it 2005-03-07
> A testcase?
>
> --
- Under
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc-apple-darwin7.8
GCC host triplet:
--- Additional Comments From schlie at comcast dot net 2005-03-04 15:26
---
(In reply to comment #12)
> Everybody who works on the AVR toolchain knows that it would be desirable to
> have attributes to allow objects to be put in and accessed in different
> address
> spac
--- Additional Comments From schlie at comcast dot net 2005-03-04 14:13
---
(In reply to comment #10)
Upon further thought, and agreeing that the explicit use of an asm macro is
likely
the most appropriate near term solution; it would appear the most ideal longer
term solution would be
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
---
(In reply to comment #6)
Nope, these are peripheral i/o registers, and like any pheripheral interface
may have
access sequence requirements which need to be satsifyed within it's driver.
These
perp
--- Additional Comments From schlie at comcast dot net 2005-03-02 23:07
---
(In reply to comment #0)
> [The follow emphasis is Atmel's from the data-sheet]:
>
> "On the AVR to do a 16-bit write, *THE HIGH BYTE MUST BE WRITTEN BEFORE THE
> LOW
> BYTE*. For a
--- Additional Comments From schlie at comcast dot net 2005-03-01 22:43
---
Subject: Re: error generated for storage class specified for
function parameter
> -- Additional Comments From joseph at codesourcery dot com 2005-03-01
> Subject: error generated for storage class spe
--- Additional Comments From schlie at comcast dot net 2005-03-01 21:41
---
Subject: Re: error generated for storage class specified for
function parameter
> --- Additional Comments From joseph at codesourcery dot com 2005-03-01
> Subject: error generated for storage class spe
--- Additional Comments From schlie at comcast dot net 2005-03-01 15:20
---
Subject: Re: error generated for storage class specified for
function parameter
> - Additional Comments From neil at daikokuya dot co dot uk 2005-03-01
>> Yes I understand. However it seems somewh
--- Additional Comments From schlie at comcast dot net 2005-03-01 03:43
---
Subject: Re: error generated for storage class specified for
function parameter
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01
> No static is wrong here, period, what you need
for storage class specified for function
parameter
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast
--- Additional Comments From schlie at comcast dot net 2005-03-01 01:02
---
Subject: Re: static initialization .data redundantly
copied to ram prior to use.
> --- Additional Comments From bjoern dot m dot haase at web dot de
> I think the key problem is, that C language p
--- Additional Comments From schlie at comcast dot net 2005-02-28 22:38
---
Subject: Re: [4.0/4.1 Regression] libgcc2.h
Improperly determines required built-in function size requirements.
> - Additional Comments From ericw at evcohs dot com 2005-02-28 22:10
> We've alread
--- Additional Comments From schlie at comcast dot net 2005-02-28 22:02
---
(In reply to comment #21)
> Hi,
>
> since this bug has been fixed by a patch of Roger Sayles a couple of weeks
> ago, I suggest to mark it as "fixed".
It's true that the o
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:55
---
(In reply to comment #10)
> (In reply to comment #9)
> > IMHO, solution of this issue would require a language different from C that
> > is
> > able to handle different classes of point
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:51
---
(In reply to comment #9)
> IMHO, solution of this issue would require a language different from C that
> is
> able to handle different classes of pointers.
Was hoping that any designated read acces
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:53
---
Subject: Re: static initialization .data redundantly
copied to ram prior to use.
> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
>
> --- Additional Comments From pinskia at gcc
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:40
---
> oh, this is still a target bug.
Possibly (but likely of similar concern for other small embedded targets)
The problem is that the initialization data which is linked in .data (stored in
readable flash/
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:24
---
(In reply to comment #3)
> *** This bug has been marked as a duplicate of 18145 ***
sorry, no.
- that bug says don't copy when there's no data to copy.
- this bug says, don't static read
Although functional, the limited read/write memory is needless used to
redundantly store
static read-only initialization data/strings effectively eliminates this memory
from having
any useful purpose.
main.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA
--- Additional Comments From schlie at comcast dot net 2005-02-25 02:06
---
Subject: Re: [4.0 Regression] wrong code for
volatile struct members
Additional Comments From rth at gcc dot gnu dot org 2005-02-25 01:57
> ---
> Fixed.
>
> --
Thank you.
--
http:/
--- Additional Comments From schlie at comcast dot net 2005-02-24 17:25
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-24
> Not a bug.
>What
--- Additional Comments From schlie at comcast dot net 2005-02-24 17:11
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> From: ericw at evcohs dot com <[EMAIL PROTECTED]>
> Can somebody with sufficient permissions please close this n
--- Additional Comments From schlie at comcast dot net 2005-02-24 16:14
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> Maybe I can be clearer, I am not stating that the avr port should not
> support 64-bit long long; just asserting th
--- Additional Comments From schlie at comcast dot net 2005-02-24 14:32
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> --- Additional Comments From schlie at comcast dot net 2005-02-24 14:22
> Subject: Re: 4.0 bootstrap unreas
--- Additional Comments From schlie at comcast dot net 2005-02-24 14:22
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
>>> Comments From ericw at evcohs dot com 2005-02-24 14:04
>>> Please explain why you think it is a
--- Additional Comments From schlie at comcast dot net 2005-02-24 10:34
---
Although I can confidently say that I've been less than enthusiastic with
some of GCC's standards interpretations; here GCC's results in each of the
examples you cite are within the set of seman
--- Additional Comments From schlie at comcast dot net 2005-02-24 02:49
---
Subject: Re: 4.0 bootstrap unreasonably requires
64-bit target type mode support.
> Please explain why you think it is a bug for the avr to support long long.
> Your description sounds like an o
port.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gn
embers?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu d
--- Additional Comments From schlie at comcast dot net 2005-02-20 06:50
---
(In reply to comment #8)
> - nor does it seem to make sence in any circumstance to referance a wider
> logical value than may be stored in a register or memory, without presuming
> it's higher-ord
--- Additional Comments From schlie at comcast dot net 2005-02-20 06:44
---
(In reply to comment #7)
With respect to: <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>
and paradoxical subreg semantics on targets which support modes_tieable
(assuming that paradoxical subreg sem
--
What|Removed |Added
Summary|make install doesn't create |make install doesn't create
|/usr/local/info/dir .../dir |/usr/local/info/dir if
esent.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc do
--- Additional Comments From schlie at comcast dot net 2005-02-18 21:57
---
(In reply to comment #6)
> Fix. http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01074.html.
For 4.0 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
--- Additional Comments From schlie at comcast dot net 2005-02-18 04:52
---
(In reply to comment #7)
> Subject: Re: [4.0 regression] Wrong loop exit
> I don't understand the comment. Comparisons constructed due to
> may_eliminate_iv are always either EQ_EXPRs or NE_EXP
1 - 100 of 192 matches
Mail list logo
