--- 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 dot org [EMAIL PROTECTED
--- 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: [EMAIL PROTECTED]
Date
--- 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 2007 22:51:25 -
To: [EMAIL
--- 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)
- For some reason, GCC is casting
--- 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 time const was
added
--- 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 defined
--- 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, based on it being
--- 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 in stage3 already
--- 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 object
--- 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 behavior
--- 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 couldn't more
--- 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 wraps around to a third
--- 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 does not store
--- 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 dot org
--- 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 says that accessing
--- 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;
still leads to the access being optimized away.
Which seems like
--- 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 reached any
--- 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/ml/gcc/2005-05/msg00073.html
- out
--- 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 assignment between
--- 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 comparison.
- Then what
--- 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 intent that lvalues which
--- 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,
these assumptions
--- 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 = will trap
is simply wrong, and is not justifyable
--- 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 reply to comment
--- 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 be cast away, there's no guarantee
--- 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 optionally
--- 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 const char []' would seem most correct
--- 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 narrow view
--- 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 NULL ptr check is not needed
--- 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 recently
filed too
--- 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 strings which
--- 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 I can't help but wonder if it may
--- 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_TYPE like INTEGER_TYPE
--- 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?
Just about any 8 or 16 bit
--- 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: ChangeLog reload.c
Is 4.1
--- 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;
}
See PR 21089.
I believe
--- 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+1.0
--- 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
should
--- 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] Initializing string
.
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
--
What|Removed |Added
Summary| initilizing string litteral|Initializing string literal
|data improperly maked frame-|data improperly marked
--- 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)
(symbol_ref/f:HI (*.LC0) [flags 0x2
--- 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
--- 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=8603action=view)
refined patch to config/avr.c required to demonstrate bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=8605action=view)
simplied test case showing static const blk mode and function bugs.
--
http://gcc.gnu.org/bugzilla
--- 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=8606action=view)
showing char function return types being incorrectly converted to int
--
http://gcc.gnu.org/bugzilla
--- 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=8608action=view)
showing problem expanding access to blk move structure move.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--
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:16
---
Created an attachment (id=8609)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8609action=view)
final resulting code showing all problems.
(including possibly one with stabs source code line correlation
--- 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 issues
: 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
: 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
--- 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=8476action=view)
proposed patch
The following patch enables small targets which don't support a 64 bit
long long type to build
--- 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_bug.cgi?id
--- 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 the dwarf-2
--- 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 defined by the dwarf-2
--- 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 with a target's run
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
CC
--- 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 fixed
--- 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-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 DONE or FAIL
--- 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 out moves by itself
--- 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?
--
- Understood. I'll post
: 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: ppc-apple
--- 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
--- 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
spaces. This has
--- 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
perpheral
--- 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 16-bit read, THE LOW BYTE MUST
--- 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 somewhat ironic
--- 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 specified
--- 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 specified
--- 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 access to data
--- 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 pointers.
Was hoping that any
--- 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 original failure mode, which
--- 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 already gone over
--- 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 permits you
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 dot net
CC: gcc-bugs at gcc dot
--- 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
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-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-only data even
--- 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/rom
--- 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 semantically consent
--- 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 bug for the avr to support long
--- 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 unreasonably
--- 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 that any port
--- 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 non-bug?
I'm
--- 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|Removed
--- 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://gcc.gnu.org
--- 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 opinion
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 gnu dot org
GCC build triplet: ppc-apple-darwin7.8
GCC
?
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 dot org
--- 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 semantics
--- 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-order bits
--- 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
.
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 dot gnu
--
What|Removed |Added
Summary|make install doesn't create |make install doesn't create
|/usr/local/info/dir .../dir |/usr/local/info/dir if
--- Additional Comments From schlie at comcast dot net 2005-02-17 13:20
---
(In reply to comment #6)
What should get a warning is the assignment of 0x80 to a char.
Not that either, as although the two differ in sign, the value does not exceed
the type's precision.
--
http
--- Additional Comments From schlie at comcast dot net 2005-02-17 14:33
---
(In reply to comment #8)
char x = 0x80; warning: value changes sign during integer type conversion
Implying an analogous warning for all assignments between dissimilarly
signed variables (i.e. signed x
1 - 100 of 191 matches
Mail list logo
