--- Comment #4 from j at uriah dot heep dot sax dot de 2010-08-12 09:54
---
(In replay to comment #1)
> That should most likely be an error instead of just a fprintf.
Agreed. What surprises me a bit that I've been under the impression
this used to work in previous releases:
--- Comment #3 from j at uriah dot heep dot sax dot de 2010-06-10 16:43
---
(In reply to comment #2)
> does provide the means to stop/start/refresh the watchdog from the
> main C program.
No. It contains a fairly detailed description how to place the
watchdog reset/initiali
--- Comment #1 from j at uriah dot heep dot sax dot de 2010-04-13 08:31
---
I think this is essentially a duplicate of bug #21018.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
--- Comment #5 from j at uriah dot heep dot sax dot de 2009-12-01 16:58
---
My first analysis shows that this is likely to be related to the
introduction of RTL prologues/epilogues in GCC 4.3. GCC 4.2.2
has:
if (avr_naked_function_p (current_function_decl))
{
fputs
--- Comment #3 from j at uriah dot heep dot sax dot de 2009-10-31 23:11
---
The bug was originally reported in the (Germany-language) mikrocontroller.net
forum, and I confirmed the bug on my local GCC 4.3.2 setup before asking
Frank to submit it as an official bug report.
--
http
--- Comment #2 from j at uriah dot heep dot sax dot de 2009-10-31 23:10
---
Created an attachment (id=18944)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18944&action=view)
Full assembler code I get from GCC 4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
--- Comment #4 from j at uriah dot heep dot sax dot de 2008-12-01 10:37
---
Note that this is a GCC 4.3.x regression; GCC 4.2.x compiled the code the
way expected.
--
j at uriah dot heep dot sax dot de changed:
What|Removed |Added
ion: 4.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37502
--- Comment #2 from j at uriah dot heep dot sax dot de 2008-02-16 22:20
---
I've got no troubles building today's SVN snapshot.
I don't know exactly how GCC's Makefile infrastructure is working, but
maybe libiberty/Makefile.in:
TEXISRC = \
$(sr
--- Comment #7 from j at uriah dot heep dot sax dot de 2008-01-20 15:21
---
(In reply to comment #6)
> Sorry, I don't have any of those trees left. But if I ever come to
> revisit those two bugs I'll make sure it fixes this bogus warning.
If you can give me some hint
--- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38
---
(In reply to comment #4)
> Oh, indeed - it also needs PR30317 fixed. (the attached patches therein
> probably no longer apply)
I applied the second of the attached patches there. It applies cleanl
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54
---
(In reply to comment #2)
> The fix for PR14495 will likely fix this (by removing the default case again).
Alas, no, it doesn't. I applied that patch (and the one it depends one
mentioned in the
--- Comment #1 from j at uriah dot heep dot sax dot de 2008-01-15 10:10
---
Created an attachment (id=14942)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14942&action=view)
Testcase showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
s function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-10 15:56
---
Some bugs appear to re-appear. :-(
While I get
__attribute__((naked))
int main(void)
{
// ...
return 42;
}
to compile with the current compiler, the following piece of code:
__attribute__((signal
--- Comment #15 from j at uriah dot heep dot sax dot de 2007-12-22 17:15
---
(In reply to comment #14)
> Note that the use of clz for the avr is avoided by using avr-libc's math
> library.
Not confirmed. A simple test program using a floating point number:
#includ
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-12-09 07:37
---
> use -Wvolatile-register-var
Could we have that at least as part of one of the "standard"
warning switch combinations, either -Wall or -Wextra? I
remember a statement from the developer who i
k
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-11-23 10:57
---
Is the missed optimization in the following code the same?
volatile unsigned char *reg_a = (unsigned char *)42;
volatile unsigned char *reg_b = (unsigned char *)34;
extern void a(void);
extern void b(void
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-11-15 21:21
---
I'm not sure whether this is related or not... but from the description, it
looks so.
avr-libc contains a macro that helps the users declaring a flash-ROM string,
lacking any real support in GCC for diff
MED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33547
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-07-26 08:41
---
Created an attachment (id=13985)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13985&action=view)
Result on avr target from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-07-26 08:40
---
Created an attachment (id=13984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13984&action=view)
Result on i386 arch from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-07-26 08:39
---
Created an attachment (id=13983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13983&action=view)
Result on i386 target from GCC 3.4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-07-26 08:38
---
Created an attachment (id=13982)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13982&action=view)
Test file
Test case. Compile with -Os -S, and optionally -DONLY_ONE_BITFIELD
to see the dif
--- Comment #32 from j at uriah dot heep dot sax dot de 2007-06-25 13:38
---
(In reply to comment #31)
> Just mentioning: printf() and std::cout need to be updated if the
> binary values are also to be *output*. Any ideas on how or where
> that is to be done?
That would be
--- Comment #34 from j at uriah dot heep dot sax dot de 2007-04-29 06:59
---
Works with GCC 4.1.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
--- Comment #5 from j at uriah dot heep dot sax dot de 2007-04-23 22:05
---
(In reply to comment #4)
> Sounds like this is a case of not reading the documentation again.
Well, unlike many others, he even *knew* something about C99, yet he
did not grok the error message's
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-04-23 21:49
---
(In reply to comment #2)
> > this message causes an unusual high amount of support traffic.
>
> Does it? This is the first time I have seen a request for a change.
When I first saw it, it took q
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-23 21:34
---
Created an attachment (id=13431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13431&action=view)
Suggested patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
s confusing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-21 09:55
---
Created an attachment (id=13400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13400&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-12 16:32
---
I disagree the "invalid syntax". According to the formal attribute syntax
description:
``Any list of specifiers and qualifiers at the start of a declaration may
contain attribute specifiers, whet
--- Comment #7 from j at uriah dot heep dot sax dot de 2007-04-10 21:04
---
Changed target triplet from avr-*-* to *-*-* as obviously, at least some
of GCC's mainstream targets are affected by that bug as well (perhaps
even *any* target).
--
j at uriah dot heep dot sax d
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-04-10 17:15
---
(In reply to comment #5)
> Inlining decisions are based on heuristics. What works for one
> target may not work quite as well for another. In this case, it
> seems that for AVR the heuristics are not
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-04-10 15:38
---
This code snippet can also be run through the i386 compiler (even though
the generated code will obviously be nonsensical). I've only got an older
version of that compiler at hand:
gcc41 (GCC) 4.1.2 200
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-04-10 14:40
---
Created an attachment (id=13347)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13347&action=view)
Generated assembly code with -Os -fno-inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-04-10 14:40
---
Created an attachment (id=13346)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13346&action=view)
Generated assembly code with -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-10 14:38
---
Created an attachment (id=13345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13345&action=view)
Test case for bug 66690.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #20 from j at uriah dot heep dot sax dot de 2007-03-12 19:55
---
(In reply to comment #19)
> Joerg, as Andrew said, you need a copyright assignment and you need to submit
> the patch to [EMAIL PROTECTED]
Patch submitted to list by 2007-02-09, message-id is
&
--- Comment #15 from j at uriah dot heep dot sax dot de 2007-02-21 19:51
---
(In reply to comment #14)
> The AVR back-end really needs improvement:
Oh, I certainly wouldn't deny that. :-)
Yes, the tendency to handle far too many items as 16 bits (the
sizeof(int) on that
--- Comment #13 from j at uriah dot heep dot sax dot de 2007-02-21 19:33
---
Created an attachment (id=13085)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13085&action=view)
Compilation result with inlining disabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
--- Comment #12 from j at uriah dot heep dot sax dot de 2007-02-21 19:32
---
Created an attachment (id=13084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13084&action=view)
Compilation result with inlined functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
--- Comment #11 from j at uriah dot heep dot sax dot de 2007-02-21 19:32
---
(In reply to comment #9)
> I don't see that adding a hook to provide target specific tuning for
> size estimates at this level is going to be useful enough to justify
> maintenance cost of suc
--- Comment #8 from j at uriah dot heep dot sax dot de 2007-02-21 17:18
---
(In reply to comment #7)
> So really this is a target specific issue I think.
The only question then is whether the current architecture allows for
tuning the costs in the target-specific files.
--
h
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-02-21 14:46
---
(In reply to comment #5)
> Unfortunately(?) the cost metrics for inlining are completely target
> independent at the moment. Can you check whether adjusting --param
> inline-call-cost will
> fi
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-02-21 12:58
---
(In reply to comment #2)
> so it believes code size is unchanged by inlining the function twice
> and removing the now unneeded out-of-line copy.
So does that mean some cost factor needs to be tuned
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-02-21 11:50
---
Created an attachment (id=13082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13082&action=view)
Sample code snippet that can be used to demonstrate the problem.
avr-gcc -DNOINLINE -Os -S bar.c
4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
--- Comment #18 from j at uriah dot heep dot sax dot de 2007-02-09 12:55
---
Created an attachment (id=13025)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025&action=view)
Updated patch, output from "svn diff" as of 2007-02-07
--
j at uriah dot heep dot s
--- Comment #16 from j at uriah dot heep dot sax dot de 2006-12-07 13:24
---
The last update of this has been about a year ago, and talked about it not
being done before GCC 4.1... Now that GCC 4.2 has been branched off, is there
any news on integrating that patch?
There'
--- Comment #8 from j at uriah dot heep dot sax dot de 2006-09-12 08:52
---
(In reply to comment #7)
> So this is not a bug. Also if libm is only the normal math library and should
> not include the soft-fp but those should be in libgcc as they are support
> functions neede
--- Comment #4 from j at uriah dot heep dot sax dot de 2006-08-14 14:28
---
(In reply to comment #3)
> -lm was not an user supplied option as shown by your commands.
>
Oh no, sorry for the confusion: it *is* a user-supplied library.
Sorry, I now see that I somehow copy&
--- Comment #2 from j at uriah dot heep dot sax dot de 2006-08-14 14:13
---
I know that the current situation for the AVR is suboptimal, there really
are overrides in libm.a for functions that are already present in libgcc.a.
However, this is not so easy to change for a number of
gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de
GCC host triplet: *-*-*
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718
--- Comment #7 from j at uriah dot heep dot sax dot de 2006-05-02 15:37
---
Forwarding this comment on behalf of Bjoern Haase:
Preliminary analysis of the RTL generated without optimization shows that
the problem is present already directly after expand. Maybe the problem
is triggered
--- Comment #6 from j at uriah dot heep dot sax dot de 2006-05-02 15:34
---
(Sorry, I hit a bit too fast.)
--
j at uriah dot heep dot sax dot de changed:
What|Removed |Added
--- Comment #5 from j at uriah dot heep dot sax dot de 2006-05-02 15:33
---
(In reply to comment #4)
> > Is this one related to PR21834?
> Anyway, my report has a preprocessed source file attached, so it
> might be more useful to non-AVR aware GCC developers.
Perhaps Ri
--- Comment #4 from j at uriah dot heep dot sax dot de 2006-05-02 15:25
---
(In reply to comment #3)
> Is this one related to PR21834?
Possible, yes. The symptoms are similar. Sorry for missing that
one at my prior search.
Anyway, my report has a preprocessed source file attac
--- Comment #2 from j at uriah dot heep dot sax dot de 2006-05-02 12:57
---
Created an attachment (id=11359)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11359&action=view)
Faulty code generated by test case.
The faulty code is in lines 136...160.
First, 8 bytes of sp
--- Comment #1 from j at uriah dot heep dot sax dot de 2006-05-02 12:54
---
Created an attachment (id=11358)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11358&action=view)
Testcase demonstrating the faulty code generated.
--
http://gcc.gnu.org/bugzilla/show_bug
j at uriah dot heep dot sax dot de
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386
--- Comment #20 from j at uriah dot heep dot sax dot de 2006-03-27 20:53
---
I suggest that this change should be accompanied by another indication in
the output that tells the ELF/DWARF-2 consumer about the changed pointer
size. Otherwise the consumer will experience "
--- Comment #6 from j at uriah dot heep dot sax dot de 2006-03-01 18:53
---
After tracking it down, it turns out to be the following change,
introduced between GCC 3.4.3 and 3.4.4:
2005-03-19 Andy Hutchinson <[EMAIL PROTECTED]>
PR target/18251
* config/avr/
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
18:55 ---
(In reply to comment #9)
Thank you very much for the useful comments.
> The patch does not document how the types of binary constants are
> determined. I suppose the rules are the same as for
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
15:18 ---
Additional remark: GAS also recognizes 0bXXX constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
14:24 ---
(In reply to comment #4)
> The main reason is because adding extensions are bad now adays. We
> are removing extensions which are not used that much and hard to
> keep working.
OK, I ac
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
13:57 ---
(In reply to comment #2)
> Confirmed, note I would actually disable binary constants by default
> instead of what the patch currently does, pedwarns about them.
Curious: why?
There are more th
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
12:24 ---
Created an attachment (id=9547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9547&action=view)
Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot)
--
ry: Implement binary constants with a "0b" prefix
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
Repor
72 matches
Mail list logo
