--- Comment #17 from bjoern dot m dot haase at web dot de 2006-08-17 14:36
---
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.
The first observation is, that when one is having a code segment
--- Comment #6 from bjoern dot m dot haase at web dot de 2006-09-06 16:51
---
To clear up the issues.
1.) libgcc provides a fp emulation based on compiled c functions that is to my
very best knowledge untested for avr and extremely inefficient.
2.) avr-libc provides fp emulation that
--- Comment #13 from bjoern dot m dot haase at web dot de 2006-09-19 20:16
---
Hello Eric,
IIRC, the bug never was really resolved. The true place to fix the issue was,
IMO, the most dreaded source file of the entire GCC source tree: reload.
My now quite old patch tried to fix the
--- Comment #8 from bjoern dot m dot haase at web dot de 2007-12-12 18:14
---
Created an attachment (id=14738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14738&action=view)
patch
My new analysis leads me to the result that the key problem of this missed
optimizati
avr on head 4.1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-04-03 14:04 ---
Hi,
I have so far found out, that the problem I have observed comes from the
configure process. For a reason, I have not figured out so far, my newly built
xgcc did try to pipe the asm sources
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC bui
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i586-linux
GCC host triplet: i586-linux
GCC target
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i586-linux
GCC host triplet: i586-linux
GCC
: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i586-linux
GCC host triplet: i586
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-04-17 23:07 ---
So probably the best thing to do now would probably be to 1.) mark the test
cases as xfail and 2.) write an enhancement request for avr-libc.?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-06 07:44 ---
It seems that when disabling two sanity checks, one again gets head to compile
also with dwarf2 support. The following patch might be a workaround until the
problem is solved by addressing it&#
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-06 13:59 ---
Hi,
I have been reviewing PR19885 and come to the following conclusions:
1.) As expected, Torleif is right: I can confirm that the problem exists,
2.) it should, however, probably be called
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-06 14:12 ---
Hi Torleif,
I have just had a look at PR19885 and I am having one additional question:
IIUC, the lable references, that eventually cause the overflow problems refer
to memory in form of "
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-30 21:16 ---
Hi,
as a step towards resolving PR19885: After looking a bit into the code of other
ports, I found out, that switching avr-gcc to the 4-byte dwarf convention
should not be complicated at all. It
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-30 21:40 ---
OK,
sorry for this, but I just realized that Darcy Watkins has made a couple of
almost exactly identical observations. Did not review all of the more recent
comments.
In case that the only
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: cygwin-x86 and linux-x86
GCC host triplet: cygwin-x86 and linux-x86
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
--- Comment #7 from bjoern dot m dot haase at web dot de 2006-05-15 17:25
---
Subject: Re: [4.1/4.2 regression] libssp causes a failure with cross compilers
mmitchel at gcc dot gnu dot org wrote on Montag, 15. Mai 2006 00:26 :
> --- Comment #6 from mmitchel at gcc dot gnu dot
--- Comment #14 from bjoern dot m dot haase at web dot de 2006-08-10 19:33
---
I had already a look at the code in the cp directory. Unfortunately the
documentation of the c++ front-end seems to be still worse than the docs on the
back-ends (i.e. RTL). Either it is virtually inexisting
--- Comment #3 from bjoern dot m dot haase at web dot de 2006-01-03 15:33
---
A patch for this issue is posted at the gcc-patches list and waits for review.
The difficulty is that libssp silently assumes that unix-style stdio is
available :-( which is not the case for embedded targets
ctly scheduled.?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-10-01 18:46 ---
The question merely is to find out if this is a bug / a bug of the
documentation or no bug at all.
After the fix for PR22000 the actual issue I had stepped over originally is
indeed fixed: The
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-05 19:47 ---
Hi,
I have the impression that the origin of the bug is not in first line linked to
a wrong assignment of types in libgcc2.
I doubt whether the problem is not linked to a problem during reload
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-06 17:35 ---
It seems that the standard says that shift operations with negative shift count
are supposed to yield an "unspecified" result.
Is there some more specific convention for gcc on how to
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-06 18:57 ---
If it would be OK for GCC to simply ignore negative constant shift counts,
the following patch would do. I have tested this with the test suite for
gcc-3.4.3 . Unfortunately avr-gcc is still broken
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-18 21:40 ---
Indeed the problem seems to be related to a problem during the reload pass. I
now think, that I have found a solution for the original problem that needs a
tiny change in the back-end.
DJ Delorie
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-18 23:27 ---
Hi,
I have just stepped over a patch suggested by Bernardo Innocenti in order to
treat the case of "shift_count == 0" correctly. My presently suggested
patch (above) only treats t
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-18 23:35 ---
I have the impression that Bug #19329 is the same as bug #19239 (as one might
think already when looking at the similarity of the numbers :-) ) 19239,
howeverr so far has addressed the issue of
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-18 23:43 ---
Sorry for this:
In my posting above, I have misspelled the bug number. I wanted to refer you
to bug #19293 (and not #19239, luckyly the number of possible permutations is
countable).
By the
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-19 21:25 ---
Hi,
here is the changed patch for avr.c . I hope that it is now compliant to the
gcc coding standards. I however did not understand what you have meant with
"this hunk adds spurious white
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-09 20:27 ---
The bug seems still to be present in head 4.0.0.
The failing example could be stripped down a little bit further:
// Begin of sample code
unsigned long semaphore_create (unsigned long name
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-09 23:14 ---
Maybe this will help to localize the origin of the bug a bit better:
I have made the observation that the presence of the bug strongly depends on
the size of the memory footprint of the structs
warf-2 support is broken for head 4.0.0
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web do
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-10 23:45 ---
Created an attachment (id=8167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8167&action=view)
Preprocessed source of the libgcc functions
This is the command I have used for generat
--
What|Removed |Added
CC||schlie at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-11 19:00 ---
I have tried to trace back the date when dwarf2 support startet to fail. So far
I have found out that it was broken already at december 5th 2004.
Yours,
Björn
--
http://gcc.gnu.org
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-11 19:04 ---
Subject: Re: [4.0 Regression] avr dwarf-2 support is broken for head 4.0
Am Freitag, 11. Februar 2005 00:36 schrieb ericw at evcohs dot com:
> --- Additional Comments From ericw at evcohs
--
What|Removed |Added
CC||bjoern dot m dot haase at
||web dot de
http://gcc.gnu.org
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-12 20:15 ---
I can confirm that the bug is present also for an intel-based linux system.
In my opinion it is absolutely not useful to define a DF mode type on the AVR
platform. Both excecution time and memory
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-12 21:08 ---
After changing line #96 in libgcc2.h from
typedef _Complex float DCtype __atribute__ ((mode (DC)));
to
typedef _Complex float DCtype __atribute__ ((mode (SC)));
it is again possible to
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-14 22:21 ---
FYI,
I have just posted a RFC on gcc@gcc.gnu.org concerning implementation of a
target-specific mode-substitution convention. Hopefully someone competent will
answer.
Yours,
Björn
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-15 23:24 ---
FYI: I have just tested the patch posted in
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html
After applying this patch, the build for the avr target again succeeds.
Yours,
Björn
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-28 21:49 ---
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".
Yours,
Björn
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-28 21:58 ---
I think the key problem is, that C language permits you to pass pointers to
your static const data structures to other functions. Possibly functions that
are not located within the same source file
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-03-03 22:21 ---
Hi,
in order to completely resolve this issue, IIUC, one would have to sacrifice
the post-increment addressing modes. In case of the X-Register, forcing the
high-byte first rule allways would
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-03-04 19:38 ---
In reply to comment #10.
I agree with you Jörg, it is not a dramatic loss if you have a bit less
efficient use of volatile pointers :-) and IMHO anybody in the avr community
could live with it. I
--
What|Removed |Added
CC||bjoern dot m dot haase at
||web dot de
http://gcc.gnu.org
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-03-04 19:51 ---
Hi,
IMHO everyone working on the avr back-end is aware of this problem. The
difficulty is, that the present architecture of the avr back-end does not
easily permit to improve this case: Every
--
What|Removed |Added
CC||bjoern dot m dot haase at
||web dot de
http://gcc.gnu.org
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-06-27 17:09 ---
Subject: Re: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
Hi Andrew,
One question about gcc policy: There exists a patch resolving 19885 since a
couple of weeks. The latest
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 06:18 ---
What's the plan? I'd like to see it in CVS. The patch I posted on gcc-patches
in may 05 is already approved (it's a straight-forward change) by Richard
Henderson.
Unfortunatel
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 06:21 ---
Sorry: Let me correct myself.
I just see that You have been refering to an earlier revision of the patch that
I had posted on this bugzilla entry. This is not the current state of the
patch. The
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 18:30 ---
>Bjorn, do you have a copyright assignment filed with the FSF?
Yes. It took quite a while but since a couple of weeks the paperwork is
finished.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-29 20:06 ---
Hi,
a couple of weeks after identifying this issue, I have continued working with
4.0.0. I never observed a similar failure in our production code. The issue
seems to be strongly linked to the
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-08-20 13:49 ---
I have re-investigated this bug today and observed that it no longer appears in
mainline. It is also absent in today's cvs state of the 4.0 branch.
Dunno whether the original problem has
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-03 14:25 ---
Hi,
I now think that the true origin of this PR is related to the fact that for AVR
we need *two* registers for holding the frame pointer:
Recently, I have played around with modifying avr-gcc
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-04 10:35 ---
Indeed IMHO the problem stems from the patch:
+2005-01-22 Roger Sayle <[EMAIL PROTECTED]>
+
+ PR middle-end/19378
+ * config/avr/avr.c (avr_hard_regno_mode_ok): R
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-04 11:28 ---
I just realized that the patch posted here had just posted had a <= where
should have been a < for two comparisons. The patch on [EMAIL PROTECTED]
is already correct.
--
http://gcc.g
1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-04 22:02 ---
Created an attachment (id=9665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9665&action=view)
Patch adding REG_EQUAL notes to the divmod4 expanders
--
http://gcc.gnu.org/b
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-05 06:59 ---
IMO, one would not be able to handle the issue by changing CSE. E.g. I
presently don't see how to avoid using register notes for the following
situation. Imagine a target not having D
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-06 07:52 ---
Do you know of any doc on how libcall block RTL is supposed to look like
(except from e.g. code reading optabs.c)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-09-06 12:59 ---
I have done some code reading now and come to the following conclusion:
When having an expanded sequence that provides one single result, libcall
blocks are an appropriate method for making sure
66 matches
Mail list logo
