--- Additional Comments From schlie at comcast dot net 2005-02-17 22:47
---
got my vote.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20016
--- Additional Comments From schlie at comcast dot net 2005-02-17 23:37
---
(In reply to comment #2)
The problem is that we reset TREE_OVERFLOW:
It would seem it overflows incremented, and underflow's decremented,
only a terminal non-zero count would represent an over/underflow
--- 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_EXPRs. Comparing
--- Additional Comments From schlie at comcast dot net 2005-02-16 11:16
---
Subject: Re: [4.0 Regression] build broken on
several targets due to recent 'DC' type update to libgcc2
From: corsepiu at gcc dot gnu dot org [EMAIL PROTECTED]
While building, I noticed warnings from math
--- Additional Comments From schlie at comcast dot net 2005-02-16 11:47
---
(In reply to comment #3)
One more note from me on this bug forever.
Most people don't use parameter names in prototypes to make sure that this
confussion does not
happen.
Actually, most people do use
--- Additional Comments From schlie at comcast dot net 2005-02-16 12:36
---
(In reply to comment #4)
To be more clear (independant of what most may or may not do, or rely upon), as
within the body
of a function definition, given that parameters are referanced by their
symbolic name
--- Additional Comments From schlie at comcast dot net 2005-02-16 15:56
---
Subject: Re: [4.0 Regression] build broken on
several targets due to recent 'DC' type update to libgcc2
Like ...?
Here's one (target: h8300-rtems4.7):
../../../../../../gcc-4.0.0/newlib/libm/math
--- Additional Comments From schlie at comcast dot net 2005-02-17 01:22
---
Not sure if it's helpful (or further complicating) but as the avr uses a
Harvard memory model; it's PC (program counter) actually references a 64K
16-bit program word address space which is orthogonal to it's
--- Additional Comments From schlie at comcast dot net 2005-02-14 20:32
---
(In reply to comment #9)
None of the primary/secondary targets are known to fail so removing the
target milestone.
Although I understand none of the failures are on primary/secondary targets,
might someone
--- Additional Comments From schlie at comcast dot net 2005-02-13 18:30
---
(In reply to comment #1)
There has to be a reason why we want to use long int instead of the integer
type which is the same size
There's no doubt that someone may have thought so, but it's wrong;
as there's
--- Additional Comments From schlie at comcast dot net 2005-02-14 05:47
---
(In reply to comment #7)
Note the code from build_binop from the C and C++ front-ends need to be moved
to fold and then
when that happens my tree combiner will just work.
Sorry, but a little confused
--- Additional Comments From schlie at comcast dot net 2005-02-14 06:04
---
(In reply to comment #5)
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html
it may be worth noting that compare for equivelence/non-equivelence,
is insensitive to the sign of equivelent rank integers
--- Additional Comments From schlie at comcast dot net 2005-02-12 07:59
---
Subject: Re: avr target build broken by recent 'DC'
type update to libgcc2
This is a complex mode of DFmode. Is DFmode supported at all on avr?
- no, but doubles are defined as being the same size as floats
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
--- Additional Comments From schlie at comcast dot net 2005-02-13 00:10
---
Subject: Re: [4.0 Regression] avr target build broken
by recent 'DC' type update to libgcc2
Or simpler, for each target (as gcc libgcc2 has trouble figuring it out):
#define CHAR_MODE QI
#define
--- Additional Comments From schlie at comcast dot net 2005-02-06 17:14
---
(In reply to comment #1)
- as I'm curious as to what the proper interpretation/handling of
target dependant constant value casts should be; it seems that in
the provided example, the optimized
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19795
--- Additional Comments From schlie at comcast dot net 2005-02-07 02:42
---
(In reply to comment #2)
Might it be possible to change the severity to at least normal
and possibly reclassify it as a mis-optimization, as it's very
typical for folks who know processors to intentionally
--- Additional Comments From schlie at comcast dot net 2005-02-07 03:01
---
(In reply to comment #5)
(In reply to comment #4)
Understood, Thanks (apparently it' becomming more important to get the costs
more correct).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19686
--- Additional Comments From schlie at comcast dot net 2005-02-02 17:54
---
Because the big number exceeds the representable precision of a double,
thereby 1 is less significant than the least significant representable magnitude
of the stored value, thereby can't effect it if summed
--- Additional Comments From schlie at comcast dot net 2005-02-02 22:16
---
(In reply to comment #23)
Just to double check, however as may be required, instructions which
may be affected by a modifyable control register state may denote that
dependance in the instruction's rtl
--- Additional Comments From schlie at comcast dot net 2005-01-25 20:33
---
(In reply to comment #9)
Not good. With these two patches applied, the size of four
big AVR applications increased slightly.
Although it would have been nicer if all 4 got smaller, it's not clear
--- Additional Comments From schlie at comcast dot net 2005-01-25 23:19
---
(In reply to comment #11)
The change described above should avoid AVR keeping HImode integer constants
in registers and then copying them when required (its as cheap to load an
immediate constant
--- Additional Comments From schlie at comcast dot net 2005-01-25 03:24
---
(In reply to comment #1)
An interesting question might be how wide is a bool type, I believe C defines
it as
having a rank less than char, and preumably at least as wide as an unsigned:1,
so
does that imply
--- Additional Comments From schlie at comcast dot net 2005-01-22 18:28
---
Subject: Re: [4.0 Regression] libgcc2.h Improperly
determines required built-in function size requirements.
Any reason that the milestone was removed vs. moved to 4.1 for tertiary
platforms?
From: mmitchel
--- Additional Comments From schlie at comcast dot net 2005-01-23 00:25
---
(In reply to comment #10)
have you had a chance to look at Roger's more recient patch:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01181.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
--- Additional Comments From schlie at comcast dot net 2005-01-22 00:53
---
just for reference, as didn't notice this pr eariler:
http://gcc.gnu.org/ml/gcc/2005-01/msg01270.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:17
---
Actually wonder if a better solutions would be to and () the rhs shift count by
Log2(rhs-mode-size) bit mask, thereby the resulting value will always be within
0 = shift = (N-1), resulting effectivly a shift
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:26
---
(In reply to comment #8)
Never mind, as it's likely not worth the bother as the behavor
is undefined anyway, and the existing proposal is simpler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
--- Additional Comments From schlie at comcast dot net 2005-01-16 17:25
---
Not sure if it's a related issue, but attempting to build an AVR cross
G++/libstdc++ complier on OSX presumes --disable-nls, nor using
glibc, fails to build ; although possibly for other reasons as well
--- Additional Comments From schlie at comcast dot net 2005-01-16 17:39
---
Subject: Re: usual arithmetic conversion not
applying correctly
From: schlie at comcast dot net [EMAIL PROTECTED]
--- Additional Comments From schlie at comcast dot net 2005-01-16 07:16
Subject: Re
--- Additional Comments From schlie at comcast dot net 2005-01-17 01:35
---
(In reply to comment #3)
Or might it be nearly just as easy to place all in the same tree initially,
and eliminate the potential ambiguity now that it's been identified?
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From schlie at comcast dot net 2005-01-17 02:14
---
(In reply to comment #4)
in referance as to why disabling typeof on bit-fields ins not a fix:
http://gcc.gnu.org/ml/gcc/2005-01/msg00916.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10333
--- Additional Comments From schlie at comcast dot net 2005-01-17 03:25
---
You mean other than the reciently filed bug Bug 19455 referanced as a duplicate
of this one, demonstraiing valid code which used to work as expected?
(wouldn't this qualify as the bug not being un-noticed
--- Additional Comments From schlie at comcast dot net 2005-01-17 05:52
---
(In reply to comment #8)
If someone complained 6 months after the change and right after 3.4.0 was
released I would not
have a
problem, but a year and a release later and the change was done on purpose I
--- Additional Comments From schlie at comcast dot net 2005-01-15 17:07
---
(In reply to comment #1)
woudn't one exect that any constant = 0 to be compatible with signed or
unsigned, where
only constants 0 should be assumed to be only compatible with signed without
a cast
--- Additional Comments From schlie at comcast dot net 2005-01-15 17:17
---
(In reply to comment #2)
where futher then any constant not explictly negative should be considerd
compatible with either
signed or unsigned assignment; thereby 0x8000 is compatible with either
--- Additional Comments From schlie at comcast dot net 2005-01-15 17:36
---
(In reply to comment #0)
Lasly, (sorry for not collecting all thoughts first), suspect the problem may
be that
~ is being considered as being analogous to an arithmetic -, which it shoudn't
be;
therefore
--- Additional Comments From schlie at comcast dot net 2005-01-15 18:09
---
(In reply to comment #4)
(again sorry), nor should ~0 be considred equivelent to -1, any more than any
explicit
non-signed constant like 0x for example be (as previously questioned), as
such
values only
--- Additional Comments From schlie at comcast dot net 2005-01-16 07:16
---
Subject: Re: usual arithmetic conversion not
applying correctly
Wonder if this PR could still be considered a missed optimization, as the
present logic which determines if an / or % expression's operands may
--- Additional Comments From schlie at comcast dot net 2005-01-14 19:40
---
(In reply to comment #3)
int val = i ? i : -1;
we convert it to unsigned because it gets promoted to unsigned because i is
unsigned and then
there is an implicit cast to int. so the type of i ? i
--- Additional Comments From schlie at comcast dot net 2005-01-15 02:38
---
(In reply to comment #5)
Yes, I apologize, I misread the the report/answer, you are of course correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
--- Additional Comments From schlie at comcast dot net 2004-12-27 18:34
---
Subject: Re: [4.0 Regression] libgcc2.h Improperly
determines required built-in function size requirements.
From: berndtrog at yahoo dot com [EMAIL PROTECTED]
--- Additional Comments From berndtrog
dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: avr-unknown-none
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19154
--
What|Removed |Added
GCC build triplet|avr-unknown-none|powerpc-apple-darwin7.7.0
GCC target triplet|powerpc-apple-darwin7.7.0 |avr-unknown-none
--- Additional Comments From schlie at comcast dot net 2004-12-25 21:39
---
Subject: Re: miss-optimization of (x pow2C) avr
conditionals returning bool equivalent values
I think the issue here is rtx_cost for avr sucks and does not give a good
accurate cost matrix.
I considered
--- Additional Comments From schlie at comcast dot net 2004-12-25 21:56
---
Subject: Re: miss-optimization of (x pow2C) avr
conditionals returning bool equivalent values
I apologize, I'm confused, what are you comparing to what?
(are you using 4.0, which to my knowledge only builds
--- Additional Comments From schlie at comcast dot net 2004-12-21 08:02
---
Problems, with 4.0 avr test results (some good, some bad, some odd);
00c6 main:
int main (void){
c6: c8 ef ldi r28, 0xF8 ; 248
c8: d0 e1 ldi r29, 0x10 ; 16
--- Additional Comments From schlie at comcast dot net 2004-12-21 20:19
---
Minimal changes required to get avr to build:
(which disables DI/DF emulation modes which appear to exceed avr's allocatable
registers. )
*** In File: config/avr.h, Beginning line: 111 ***
#define
--- Additional Comments From schlie at comcast dot net 2004-12-21 20:50
---
(although not the most elegant fix)
This fixes the rest of the problem, as there's no reaon to default promote
smaller than int sized
integers to int, they will end up being promoted if required by the back
--- Additional Comments From schlie at comcast dot net 2004-12-21 07:59
---
Problems, with 4.0 avr test results (some good, some bad, some odd);
00c6 main:
int main (void){
c6: c8 ef ldi r28, 0xF8 ; 248
c8: d0 e1 ldi r29, 0x10 ; 16
: 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
GCC build
--- Additional Comments From schlie at comcast dot net 2004-12-14 16:51
---
Subject: Re: 4.0 build failure resulting in internal
compiler error, not diagnostic.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
--- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From schlie at comcast dot net 2004-12-14 12:33
---
Subject: Re: [3.4/4.0 Regression] ~6x+ performance
regression, constant trees not being computed.
Nope, unfortunately not as of yesterday, since reload.c was tweaked last
week.
--
http://gcc.gnu.org
warnings during 4.0 build
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
--- Additional Comments From schlie at comcast dot net 2004-12-14 02:13
---
Thank you all; and would like to try to verfiy on 4.0 as well
once we can figure out now to get the avr target to reliably build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
: critical
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: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC
--- Additional Comments From schlie at comcast dot net 2004-12-09 15:23
---
Subject: Re: [3.4/4.0 Regression] ~6x+ performance
regression, constant trees not being computed.
Few thoughts:
- I believe avr's back end does know how to convert:
((char)x pow2-const) = bit-test x log2
--- Additional Comments From schlie at comcast dot net 2004-12-09 15:52
---
Subject: Re: [3.4/4.0 Regression] ~6x+ performance
regression, constant trees not being computed.
Sorry, lost the fact that only a single bit needs to remain significant in
the resulting trasform
-in
function size requirements.
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
--- Additional Comments From schlie at comcast dot net 2004-12-08 15:24
---
Subject: Re: libgcc2.h Improperly determines required
built-in function size requirements.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
--- Additional Comments From pinskia at gcc dot gnu dot
--- Additional Comments From schlie at comcast dot net 2004-12-08 20:25
---
Subject: Re: libgcc2.h Improperly determines required
built-in function size requirements.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08
Is this really a bug as almost all 8
--- Additional Comments From schlie at comcast dot net 2004-12-07 14:36
---
Subject: [3.4/4.0 Regression] -ftrapv borks up simple
integer arithmetic
--- Additional Comment #8 From Eric Botcazou 2004-12-06 18:45
The (useless?) mode promotion from SImode to DImode comes from
--- Additional Comments From schlie at comcast dot net 2004-11-24 16:10
---
but could be helpful, and couldn't hurt to clean things up rather than maintain
an otherwise needless
difference, as the fix has already also been imported into gdb's sources as
well; as just a though
--- Additional Comments From schlie at comcast dot net 2004-11-23 13:49
---
Subject: Re: missed volatile variable optimizations
Reviewing the rtl dump of the code, it does appear that SI mode volatile
and nonvolatile variables are being initialized similarly (through an
intermediate
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 host triplet: ppc
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617
--- Additional Comments From schlie at comcast dot net 2004-11-17 07:21
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1
From: dmixm at marine dot febras dot ru [EMAIL PROTECTED]
But foo_ll (shift loop with count 62!) and foo_l have remained on old -
through shift
--- Additional Comments From schlie at comcast dot net 2004-11-11 15:51
---
Subject: Re: 3.4.3 ~6x+ performance regression vs.
3.3.1, constant trees not being computed.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
--- Additional Comments From pinskia at gcc dot gnu
--- Additional Comments From schlie at comcast dot net 2004-11-11 17:19
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
From: joseph at codesourcery dot com [EMAIL PROTECTED]
--- Additional Comments From joseph at codesourcery dot
--- Additional Comments From schlie at comcast dot net 2004-11-11 20:28
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
From: joseph at codesourcery dot com [EMAIL PROTECTED]
--- Additional Comments From joseph at codesourcery dot
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: dmixm at marine dot febras dot ru,ericw at evcohs dot
com,gcc-bugs at gcc dot gnu dot org
GCC build triplet: any
GCC host triplet: any
GCC target triplet
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:15
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
Yes but regardless of the size of the constant 1:
if (a (1L 24)) or (a (1 24)) yields the same results
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:55
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote:
When I did 1 24 I got a warning (at least on the mainline
--- Additional Comments From schlie at comcast dot net 2004-11-11 04:33
---
Subject: Re: 3.4.3 ~6x+ performance regression vs.
3.3.1, constant trees not being computed.
As implied earlier, this problem may be related to (in my words) an overly
complicated and error prone processes
--- Additional Comments From schlie at comcast dot net 2004-11-11 04:59
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
--- Additional Comments From pinskia at gcc dot gnu
--- Additional Comments From schlie at comcast dot net 2004-10-20 18:34 ---
Subject: Re: wrong code emitted
Hi Andrew,
Please correct the failure mode description to critical, wrong code,
as upon reviewing the avr.md file, it's now clear that this isn't a
missed optimization; GCC
--- Additional Comments From schlie at comcast dot net 2004-10-20 19:14 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Please read rule 1:
If both operands have the same type, then no further conversion is
needed. (no promotion to int is specified or implied
--- Additional Comments From schlie at comcast dot net 2004-10-20 19:33 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Maybe the confusion is that you're not recognizing that:
char, short, int, long, long long, are all integer types, with different
storage
--- Additional Comments From schlie at comcast dot net 2004-10-20 21:19 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Andrew,
Yes, and with respect to / and % operations:
- the modulo/reminder result can always be represented in the same type
and size as its
--- Additional Comments From schlie at comcast dot net 2004-10-20 21:46 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Andrew,
And if it's already declared as, or cast to signed char's in the code?
unsigned char x, y ;
(signed char)x = (signed char)x / (signed
--- Additional Comments From schlie at comcast dot net 2004-10-20 22:27 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Andrew,
It has nothing to do with optimizing code, if the 3.X and 4.X front-ends
are promoting the size of anything other than bool, enum
--- Additional Comments From schlie at comcast dot net 2004-10-20 23:28 ---
Subject: Re: usual arithmetic conversion not
applying correctly
What size promotion is required for char sized integer operations?
I see none?
What size promotion is required for short sized integer
--- Additional Comments From schlie at comcast dot net 2004-10-21 01:04 ---
Subject: Re: usual arithmetic conversion not
applying correctly
Ok, a more basic observation/recommendation: the front end should not be
masking true operand types by promoting them prematurely
--- Additional Comments From schlie at comcast dot net 2004-10-21 01:28 ---
Subject: Re: usual arithmetic conversion not applying
correctly
Andrew,
So regardless of the all other things, it seems minimally clear that
the promotion code as it stands now should allow the required
-in functions selected
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs
--- Additional Comments From schlie at comcast dot net 2004-10-19 20:27 ---
Created an attachment (id=7378)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7378action=view)
main.c (with embedded commented out main.lss and makefile)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:18 ---
Subject: Re: wrong built-in functions selected
Nope, please look at the coded examples:
- they demonstrate that:
(signed char) % (signed char) = invokes (int) % (int), not correct.
- and the compiler
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:31 ---
Subject: Re: wrong built-in functions selected
As of course otherwise then, what's the purpose of s/u 8-bit / and %
built-in functions, if not to enable their use when all the operands are
type compatible
--- Additional Comments From schlie at comcast dot net 2004-10-19 21:53 ---
Subject: Re: not using qi version of divmod
I agree that the missed optimizations won't produce incorrect results, just
very inefficient ones. As all rhs argument optimizations seem to be properly
identified
--- Additional Comments From schlie at comcast dot net 2004-10-19 22:31 ---
Subject: Re: not using qi version of divmod
Hi Eric,
Out of curiosity, what exactly is the 10733 bug, is wrong result computed?
If so, that implies that divmodhi is broken; otherwise it's not a bug
--- Additional Comments From schlie at comcast dot net 2004-10-20 04:15 ---
Although I don't know what problem may have existed, but the code documented produces
a correct
result of 12 in all cases; so this bug should probably be closed.
-paul-
--
http://gcc.gnu.org/bugzilla
101 - 191 of 191 matches
Mail list logo
