As Philipp Schafft wrote:
Please note that fflush() doesn't do that on any system. It only flushes
the buffers within the FILE* object.
This is the most convincing argument so far. As avr-libc's stdio does
not perform any buffering at the stdio level, fflush() can only be
implemented as a
Update of bug #37149 (project avr-libc):
Originator Email: = katja.schwie...@atmel.com
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?37149
___
Update of bug #37104 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Georg-Johann Lay wrote:
C89 is a subset thereof, and the problem is also present with
-std=c90.
ANSI C89 and ISO C90 are synonyms.
However, GCC itself does not have a feature to compile to MISRA
(AFAIK) so it makes it difficult to fully comply.
(Though I've wanted to add that
As Weddington, Eric wrote:
...instead of __inline or similar to make it work together with -std=c89
Sorry, but what's the bug here?
That our library code is supposed to be compatible to any -std= option
(except where documentation explains something else, e.g. in the
util/atomic.h stuff).
As Weddington, Eric wrote:
The counter argument, though, is that C89 is already pretty old. Do
we need to comply with that standard? Or are we just going to comply
with the C99 standard?
What is our policy?
The policy is to be as liberal as reasonably possible. ;-)
In the current case,
As Weddington, Eric wrote:
I would hate to say, We have to use C99 for some avr-libc modules
(atomic.h), but we guarantee C89 compliance for other avr-libc
modules (delay.h). We really should be consistent across the whole
project. Which means that if we guarantee C89 compliance for one
As Thomas, George wrote:
I got error message saying missing file optimize.dox in doc/api/optimize.dox
when I was trying to build the the documentation of libc.
I noticed this problem only slightly after releasing version 1.7.1.
It's fixed in the current Makefiles, but due to that omission, it
Update of bug #36581 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of bug #36454 (project avr-libc):
Status: In Progress = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 1.8.1
Update of bug #36454 (project avr-libc):
Status:None = In Progress
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
Would this help?
Follow-up Comment #3, bug #36454 (project avr-libc):
Another try:
Index: include/string.h
===
--- include/string.h(revision 2291)
+++ include/string.h(working copy)
@@ -110,7 +110,7 @@
extern int ffs (int __val)
URL:
http://savannah.nongnu.org/bugs/?36350
Summary: FUSE4_DEFAULT wrong for Xmega A devices
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Mon 30 Apr 2012 01:50:42 PM CEST
Category: Header
Follow-up Comment #1, bug #35539 (project avr-libc):
We should probably audit the standard to ensure there are no
more slips like that one.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?35539
Update of bug #35483 (project avr-libc):
Severity: 3 - Normal = 1 - Wish
___
Follow-up Comment #1:
All that stuff still originates from Ted Roth's initial work on the
autoconf setup (back in
Update of bug #35467 (project avr-libc):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Sorry, no, this is
As Bill Westfield wrote:
In the case where a size-limited program is only using one interrupt
(this is usbtiny on an ATtiny2313, and avr-gcc 4.3.2), is there a
good way to get an abbreviated vector table instead of having
vectors for everything?
I think the best way is to clone gcrt1.S into
As Georg-Johann Lay wrote:
Jörg, would it help to make ./crt1/gcrt1.S:__vectors weak so that
user can provide his own vector table?
Don't know. Someone could give that a try, and if it works, we change
the library definition. That someone would hopefully also write up
a few lines for the
As Bill Westfield wrote:
However, if I link
with -nostartfiles I seem to get the desired behavior.
That's what you are supposed to do, yes.
How is the crtxxx file linked into the final target? In order for the
weak symbol to be overridden by my own definition, it would have to be
treated
As Jan Waclawek wrote:
Just want to remark that these issues had been discussed already in
the thread stemming from
http://lists.nongnu.org/archive/html/avr-libc-dev/2011-09/msg00025.html
...
And the outcome was that the macro solution is not really suitable
as a replacement. To quote
As David Brown wrote:
Being able to attach the progmem attribute to the type is a useful
feature - or it would be, if it were safe to use. The main reason, as I
see it, is the same with all type information - it helps improve the
safety, static (compile-time) error checking, and
As David Brown wrote:
Would it be possible to replace the typedef with a #define?
That's always problematic, given the vastly different way between
the way a macro and a typedef are actually operating.
I haven't looked at it in detail, so that's just a stab in the dark
- but it might get the
Update of bug #35226 (project avr-libc):
Status:None = In Progress
Assigned to:None = joerg_wunsch
Release: Any = 1.8.0
Update of bug #35226 (project avr-libc):
Status: In Progress = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 1.8.1
Update of bug #34345 (project avr-libc):
Status: Need Info = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Yes, it is. 1.8.0 is out, with the usual SVN tag.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
As Joerg Wunsch wrote:
Re-apply the commit for changeset 2257, now that 1.8.0 has been
released.
NB: this currently breaks the build for AT43USB320 devices.
It would be great if someone could go along, and fix the build now so
the tree doesn't remain broken again for such a long time
As Jan Waclawek wrote:
The mentioned changeset attempts to fix the problem which causes the
binary library form of Carlos Lamas's functions for accessing 64kW
FLASH be broken ever since included in avr-libc v1.7 …
While the userbase who wish to use said functions might be a
negligible
Follow-up Comment #4, bug #34345 (project avr-libc):
Please test again with a current doxygen. I've got 1.7.6.1
here, and everything works fine with that.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?34345
Update of bug #34002 (project avr-libc):
Status: Need Info = Works For Me
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #32773 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 1.8.0
Update of bug #31267 (project avr-libc):
Status:None = In Progress
___
Follow-up Comment #3:
I opened an Atmel bug report for this, requesting the removal
of these vectors from the
I intended to release avr-libc 1.8.0, as I've got downstream bug
reports for things that have long been fixed in SVN.
However, the current build is completely broken. First, changeset
2257 break the build for architecture avr31, as it results in an
attempt to evaluate AVR_RAMPZ_ADDR for device
Update of bug #35020 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of bug #35003 (project avr-libc):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #4:
You'd be surprised
As Jan Waclawek wrote:
Do you find that a sufficient documentation of this feature?
Strictly, that description is only guaranteed to apply to the SEI
instruction, not to other ways that modify the I flag. Apparently,
this one-instruction delay is implemented in the classic AVR core in a
way
As jerrykmhan wrote:
When I used the function pow() and log10() at the same time then the
GCC displayed the up error message.
Please add the math library (-lm) to the list of your libraries.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
As Georg-Johann Lay wrote:
./configure --disable/enable-shared/static
Don't do that.
I thought this was referring to the way the prerequisite libraries
(gmp, gpc, mpfr) are configured. But upon re-reading, it's not quite
clear what Volker was really about to say here.
--
cheers, Jorg
As Volker Kuhlmann wrote:
I had already posted my solution. To recap, the problem is parsing
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__((__mode__ (__HI__)));
typedef int int32_t __attribute__((__mode__ (__SI__)));
with any
As David Brown wrote:
The other possible issue that springs to mind is debuggers - will
debuggers always be happy with non-standard definitions of the types?
At least GDB apparently doesn't have a problem, and very likely the
AVR Studio (4 5) debuggers neither. Otherwise, we'd already knew
As David Brown wrote:
That might be okay. However, why not do this:
#if defined(__DOXYGEN__)
#define __attribute__(discard)
#endif
I don't know whether doxygen's preprocessing stage will really work
correctly with that. Otherwise, it might be fine.
A char * can alias any other type,
As Volker Kuhlmann wrote:
I've been trying for 3 days now (incl half a weekend) to get 4.6.2 to
compile and I have to say build instructions are shockingly bad. What
worked for 4.3.3 just wasted 3 days for me.
If you look into the correct (out of the many ;) config.log files,
you'll see the
As David Brown wrote:
The reason I questioned the signed char case was from a quotation
from the standards in a stackoverflow question, which suggests that
it only applies to plain char and unsigned char. I don't have a
copy of the standards on-hand to check. It may also be that it
applies
As Weddington, Eric wrote:
So please realize that they are not *trying* to spread FUD. They
just don't have the resources to tackle the toolchain issues
in-depth.
I've only been grumbling since a half-sentence just saying that newer
versions suffer from various problems apparently has such an
As Volker Kuhlmann wrote:
Good idea as well. Johann did a lot of work on the AVR part of GCC
recently, and he also backported all of the more important bug fixes
to GCC 4.6.x.
= Georg-Johann Lay?
Yes.
But: use GCC 4.6.3 rather than 4.6.2, so you benefit from the C++
progmem string
Follow-up Comment #2, bug #34695 (project avr-libc):
On a second thought: generally preparing our header files for
being more lint-friendly might be a good idea. Everything
should be wrapped within #ifdef __lint where needed. This
should in particularly consider the commonly used splint
Update of bug #34680 (project avr-libc):
Status:None = Need Info
___
Follow-up Comment #1:
I'm not quite sure whether the bug report is _only_ about
PSTR needing to declare the string as
Follow-up Comment #4, bug #28837 (project avr-libc):
As it's a GCC bug which has already been fixed there, and it only
produces a warning, I somewhat hesitate to add hacks in avr-libc for
that.
Would there be any point in moving all PSTR data (independent of the
GCC version) to .progmem.data?
Update of bug #34680 (project avr-libc):
Status: Need Info = Fixed
Assigned to:None = joerg_wunsch
Fixed Release:None = 1.8.0
Update of bug #34680 (project avr-libc):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?34680
___
As Bob Paddock wrote:
As it's a GCC bug which has already been fixed there, and it only
produces a warning
It makes C++ code unusable if the local policy is zero tolerance for
warnings.
Then either don't use C++, or change that policy (it would suffice to
allow blessed warnings, based on
As Volker Kuhlmann wrote:
Just because someone at Arduino thinks ``4.4.x and 4.5.x seem to have
various problems'' is enough to make you not using them?
Yes, definitely. Why?
I have no other information and know nothing about the avr-gcc specific
issues in gcc.
The least you could
Update of bug #34560 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Bernhard Kuemel wrote:
I could ask Atmel. They do respond to such questions. I'm pretty sure it
is ok to jump across flashend.
I think that might be useful, just to be sure.
Should the odd case happen, that the application starts beyond the
range of rjmp I have to use jmp in the loader.
Update of bug #34423 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Follow-up Comment #4, bug #34423 (project avr-libc):
Addendum: I've got the hint that this is likely being fixed
in GCC 4.6.2.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?34423
Follow-up Comment #5, bug #34423 (project avr-libc):
I tried to backport the change from GCC's trunk to version
4.5.x, which appears to be successfull. I think it indeed
solves the issue.
Patch attached, if you're brave enough to give it a try, and
compile your own compiler with it.
(file
Follow-up Comment #1, bug #34423 (project avr-libc):
I don't understand that half-sentence:
``and that's why the MSB of temp is lost''
Even without inlining, the correct functionality should be
achieved.
Btw., drop those pointless -f options. If you want short
enums, use
As Weddington, Eric wrote:
The last time we talked about a release was to do 1.8.0, after we go
through the bug list.
Oops, you're right, I eventually forgot about that. ;-)
OK, so consider it being a 1.8.0-rc, despite of its name ... After
all, the reason for the 1.8 bump was the poisoning
Update of bug #34345 (project avr-libc):
Status:None = Need Info
___
Follow-up Comment #1:
Which doxygen version are you using?
Update of bug #34047 (project avr-libc):
Item Group: libc code = Header files
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:
As Bill Westfield wrote:
Are there any test suites of the avr-libc functions/etc?
Yes, they are located in the subdirectory tests/ in the source tree.
I'm particularly looking for things that test pgmspace.h
There's nothing directly for that it seems, although there's a
subdirectory pmstring
As Boyapati, Anitha wrote:
Hmm, I am using 1.7.1 release version. Let me see what the
differences are..
Yes, this is a post-1.71 fix.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating
As Dmitry E. Oboukhov wrote:
avr-libc or avr-libc-dev?
I had subscribed avr-libc-dev and then sent the mail.
avr-libc-dev is OK. However, you've used your debian.org address to
subscribe, but are posting from another address. Hint: in order to
get both addresses as valid posting addresses,
As Bradley Jarvis wrote:
So please ignore this patch, I will use the
_vect vectors from now on.
Glad to hear it works for you!
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you
As Weddington, Eric wrote:
It describes the two different naming systems, but you're right, it
doesn't seem to explicitly say that the SIG_ names are
deprecated. Joerg, we will need to change that.
Some work needs to be spent there anyway. This entire documentation
part used to be
As Weddington, Eric wrote:
Well I'd say that that is a theoretical difference. As we've seen,
we can't rely on the fact that the XML device files are always
up-to-date. We have plenty of situations where the datasheets are
updated first and the XML files are afterward, even by some amount
of
Update of patch #7531 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of patch #7464 (project avr-libc):
Status:None = Need Info
Assigned to:None = joerg_wunsch
___
Follow-up Comment #2:
I don't really
Update of patch #7362 (project avr-libc):
Status:None = Done
Assigned to: aboyapati = joerg_wunsch
Open/Closed:Open = Closed
As Weddington, Eric wrote:
Did you check the latest XML device files that come with AVR Studio?
I've got earlier XML files around, they contain these definitions,
yes.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC:
As Joerg Wunsch wrote:
I've got earlier XML files around, they contain these definitions,
yes.
Ah, they've once been named without the `L'; that's what we've
got in our header files still. According to my CVS logs of the
XML files, these registers have been renamed between AVR Studio
versions
As Weddington, Eric wrote:
- couldn't find instructions on how to fill out a bug report -
pointers appreciated
Avr-libc project here:
https://savannah.nongnu.org/projects/avr-libc
Scroll down to Bug Tracker, click on Submit New Item.
These are the instructions for the next time. ;-)
I
As Weddington, Eric wrote:
Give me some time for a thorough sweep through the bug and patch
list before.
Hey, I had a thought. (Scary, I know.) Do you think that we might be
able to do a first and completely clear out the bug list for
avr-libc? I don't even remember the last time we did
As Weddington, Eric wrote:
Any thoughts to the timing of a 1.7.2 release?
Give me some time for a thorough sweep through the bug and patch list
before. Of course, anyone else (with SVN commit privs) is also
welcome to apply patches and bugfixes. Just don't forget the
documentation.
I shall
Update of bug #33238 (project avr-libc):
Status:None = Fixed
Fixed Release:None = 1.7.1
___
Follow-up Comment #1:
This bug has been
Update of bug #33238 (project avr-libc):
Category:None = Header
Item Group: libc code = Header files
___
Reply to this item at:
As Boyapati, Anitha wrote:
The build errors can be safely ignored. This is because of empty io
header files used for xmega32X1 and Xmega128B1. gcrt1.S requires
some definitions like __VECTORS_SIZE to be initialized in header
files. Since it does not find them, gcrt1.S could not expand
Follow-up Comment #4, bug #30436 (project avr-libc):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?30436
___
Message sent
As Weddington, Eric wrote:
Anitha, there is a separate drop-down box for this information that
needs to be set, rather than putting a comment in the bug report.
... which I forgot to update when I rolled the 1.7.1 release. Anitha
just reminded me.
--
cheers, Jorg .-.-. --...
As Bill Perry wrote:
The only thing left (for me) is the possibility of adding a
_delay_ns() function.
Are you willing to submit that as a patch against the current SVN
version?
If so, please don't forget the documentation (which is just the
doxygen comment on top of it). The documentation
As Weddington, Eric wrote:
I question the whole viability of a _delay_ns() function. If someone
wants a resolution that small, then they should be able to do the
calculation and use the __builtin_avr_delay_cycles() builtin
function instead.
But that way, you might as well question the other
As Weddington, Eric wrote:
Well, certainly there is *some* testing, but as you can see it could
certainly use improvement.
In particular, it might need more testcases.
Ideally, it should be tested for all devices, but that's now well
over 100 devices.
That wouldn't have helped in the delay
As Boyapati, Anitha wrote:
I recently saw new/delete operator support being requested. This
made me think about C++ support. Likewise any such features in the
long run maybe...
Yes, libstdc++ support is on the wishlist, even though it's beyond the
scope of the avr-libc project.
Likewise,
As Boyapati, Anitha wrote:
Ok. I am referring to 'Latest NEWS' from
https://savannah.nongnu.org/projects/avr-libc/.
OK, I constantly forget about this one, too. Btw., I updated your
permissions for News items, you are now able to post and approve News
items yourself, Anitha.
Another
As Bradley Jarvis wrote:
I am happy to have a look at adding libstdc++ because I am quite
interested in using exceptions, but I won't be able to get around to it
for a few months. ...
I have noticed that stdlibc++ is located in gcc not glibc, what were
your ideas on implementing? I suppose
As Boyapati, Anitha wrote:
Can we update the Latest NEWS section too? Looks like not many are
aware of the release unless it got spread through word of mouth...
I did what I do with every release: I copied over the NEWS file from
the release to NEWS.txt on the webserver. That's why the URL
As Bradley Jarvis wrote:
With regard to patch's I have submitted another one and just wondering
what the process for getting patches applied to the source?
Well, some developer has to review them, and apply them.
I'm still hoping we would find someone to implement a real libstdc++ :)
so all
Well, finally, a new release.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-libc-dev mailing
As Bradley Jarvis wrote:
Ok I found the problem, the makefile adds the -mmcu argument to CFLAGS
but not CPPFLAGS which is new. So new.cc is not compiled to the correct
avr architecture.
No, please *don't* use the name CPPFLAGS when referring to C++.
CPP as a synonym for C++ might have some
As Dave Hylands wrote:
And just to make it brutally clear, you have my permission to use the
code, and put whatever license it is you need to use it in avr-libc.
:-)
OK, thanks, the license is already on top of util/crc16.h, so it
could just be added there.
--
cheers, Jorg
As Boyapati, Anitha wrote:
Err..I thought all fixed and closed bugs can have locked
discussions. No? I mean if a bug is re-opened can not the discussed
be unlocked?
Normal users (i.e. everyone except the admins/technicians of the
affected project) cannot change the state of an item (bug,
As Frédéric Nadeau wrote:
I found this BSD project that has the code
implemented and it worked for me.
http://www.google.com/codesearch/p?hl=fr#M2_HPf5NDc8/trunk/2009/robostix/robostix/Shared/Crc8.c
Unfortunately, despite of google claiming so in the header, it's not
BSD-licensed but GPLed.
As Frédéric Nadeau wrote:
Alternatively, this software may be distributed under the terms of
BSD license. See README and COPYING for more details.
OK, in that case it's fine.
I'm no license expert and my understanding is that GPL and BSD are
defacto incompatible... So I don't know if one
As Bradley Jarvis wrote:
The wrapper functions appear to work quite well and the class objects
created with new do behave like one created using gcc for the x86 arch
including running the constructor and destructor.
I've got only two concerns about that:
. This your email will get lost in
Hi Anitha,
How about planning for 1.7.1 release next week? Its been a while
since we gave any release...
Exactly. ;-) Incidentally, yesterday I've been thinking about
releasing new versions of all the tools where I'm the de-facto release
engineer (avr-libc, avrdude, avarice) really soon now,
As Boyapati, Anitha wrote:
I think patches are available for following bugs:
https://savannah.nongnu.org/bugs/?31990
https://savannah.nongnu.org/bugs/?31873
Then, please go ahead, and commit everything you are confident with.
Please don't wait for someone else to commit it.
--
cheers,
As Bradley Jarvis wrote:
I have had a look at gcc for the i686 and new and delete functions
appear to be located in the library libstdc++ .
Yes, but this one, we don't have -- that's why we need the workaround
at all. Btw, new and delete are language keywords (operators) in
C++, so they are
Update of bug #32322 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Follow-up Comment #3, bug #32086 (project avr-libc):
I attached a demo project with makefile to test it for you!
Not very helpful. I already wrote that I cannot reproduce it,
but if you don't believe it:
j...@uriah 86% gmake
rm -rf *.o demo.elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map
201 - 300 of 868 matches
Mail list logo
