Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

ssage From: Stu Bell Date: 10/02/2017 03:58 (GMT+01:00) To: David Brown , Bob Paddock , avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering   code" I hate to stick my nose in this after years away from the list, but... David is

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

I hate to stick my nose in this after years away from the list, but... David is right about the problems with atomic functions in C. The good news is that there /is/ another solution: Use assembly language. That does not solve the problem within the domain of C, but it /does/ solve the problem

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

David, Thanks for pointing out the right place to submit the bug report. I have submitted one here: https://savannah.nongnu.org/bugs/index.php?50270 Best regards, Marcin Godlewski W dniu 2017-02-09 15:14:11 użytkownik David Brown napisał: > You could file this as a bug on the website: >

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

On 09/02/17 19:49, Bob Paddock wrote: On Thu, Feb 9, 2017 at 1:13 PM, David Brown wrote: Note also that it is only control of the memory access that is needed for code correctness - moving instruction execution affects timing, but not the results. As I'm sure you are aware even if the code

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

On Thu, Feb 9, 2017 at 1:13 PM, David Brown wrote: > Note also that it is only control > of the memory access that is needed for code correctness - moving > instruction execution affects timing, but not the results. As I'm sure you are aware even if the code if mathematically correct, giving the

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

The functions in atomic.h are correct, but their description is not quite accurate. The description says that inside an atomic block, the code cannot be interrupted. But as we have seen, /code/ can be moved inside and outside of an atomic block just as it can be moved around the "cli()" instr

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Are the functions like macros in atomic.h correct? They attempt to deal properly with critical sections/code motion etc, in what this thread is discussing. http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html On Thu, Feb 9, 2017 at 9:14 AM, David Brown wrote: > You could file th

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

You could file this as a bug on the website: As far as I understand it, the documentation (both on the website and the Atmel documentation) is generated directly from the library code and comments - so this would be a change to the library source.

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Dear All, The site http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder/optimization_1optim_code_reorder.html still contains buggy description of memory barriers in avr-gcc. As this site is popular among avr users I think it's really worth fixing. What is more the sa

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

W dniu 2016-12-09 10:11:55 użytkownik David Brown napisał: > On 08/12/16 21:46, Georg-Johann Lay wrote: > > Marcin Godlewski schrieb: > >> Dear all, > >> > >> Thanks for the reply to David. However I'm not trying to find a > >> solution for the described issue. What I'm trying to say in this > >>

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Please see my answer at the bottom. W dniu 2016-12-09 09:15:24 użytkownik David Brown napisał: > On 08/12/16 21:55, Marcin Godlewski wrote: > > > > > > W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay > > napisał: > >> Marcin Godlewski schrieb: > >>> Dear all, > >>> > >>> Thanks for th

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

On 08/12/16 21:46, Georg-Johann Lay wrote: > Marcin Godlewski schrieb: >> Dear all, >> >> Thanks for the reply to David. However I'm not trying to find a >> solution for the described issue. What I'm trying to say in this >> e-mail is that this part of Atmel documentation: >> http://www.atmel.com/w

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

On 08/12/16 21:55, Marcin Godlewski wrote: > > > W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay > napisał: >> Marcin Godlewski schrieb: >>> Dear all, >>> >>> Thanks for the reply to David. However I'm not trying to find a solution >>> for the described issue. What I'm trying to say in

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Marcin Godlewski schrieb: Dear all, Thanks for the reply to David. However I'm not trying to find a solution for the described issue. What I'm trying to say in this e-mail is that this part of Atmel documentation: http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reo

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay napisał: > Marcin Godlewski schrieb: > > Dear all, > > > > Thanks for the reply to David. However I'm not trying to find a solution > > for the described issue. What I'm trying to say in this e-mail is that this > > part of Atmel document

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay napisał: > Marcin Godlewski schrieb: > > Dear all, > > > > Thanks for the reply to David. However I'm not trying to find a solution > > for the described issue. What I'm trying to say in this e-mail is that this > > part of Atmel document

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Dear all, Thanks for the reply to David. However I'm not trying to find a solution for the described issue. What I'm trying to say in this e-mail is that this part of Atmel documentation: http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html is innacurate and

Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

On 07/12/16 00:42, Marcin Godlewski wrote: > Dear all, > > I'm writing with reference to the following paragraph in avr libc manual: > http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder > > It is stated there: "However, memory barrier works well in ensuring that > a

[avr-gcc-list] Avr-libc-user-manual: "Problems with reordering code"

Dear all,   I'm writing with reference to the following paragraph in avr libc manual: http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder   It is stated there: "However, memory barrier works well in ensuring that all volatile accesses before and after the barrier occur

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Erik Walthinsen wrote: > On 02/16/2014 12:48 PM, Joerg Wunsch wrote: >> As far as avr-libc is concerned, that's not necessary, since it's BSD-style >> licensed. > No, but for gcc and binutils getting the patches upstream does require > FSF paperwork. I think adding a new device should count as

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

On 02/16/2014 12:48 PM, Joerg Wunsch wrote: As far as avr-libc is concerned, that's not necessary, since it's BSD-style licensed. No, but for gcc and binutils getting the patches upstream does require FSF paperwork. However, I have no idea how much it would take to actually get the maintainer

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Erik Walthinsen wrote: > I'll gladly file the assignment paperwork with the the FSF to be able to > get this stuff done myself, it somebody will let me. As far as avr-libc is concerned, that's not necessary, since it's BSD-style licensed. Yes, I'm guilty of doing too little avr-libc work in th

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

On 02/14/2014 12:04 AM, Joerg Wunsch wrote: Alas, since the day when Anitha Boyapati has left the Atmel team that handles the AVR tools, there has not been much contribution back from Atmel to avr-libc. Instead, they maintain their own set of patches (until it will eventually become unmaintainab

Re: [avr-gcc-list] avr-libc does not have support for, ATxmega16a4u or ATxmega32a4u

text. Regards David -- Message: 1 Date: Fri, 14 Feb 2014 09:04:25 +0100 (MET) From:j...@uriah.heep.sax.de (Joerg Wunsch) To:avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4uor ATx

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

David Fernandez wrote: > Anybody knows if there is a script to create the io files for these two > processors? or if there is some procedure to create them? Should be possible, but it's more than the IO header files. Some #ifdefs need to be extended, too. Alas, since the day when Anitha Boyap

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Update your Atmel toolchain. I have linux 3.4.3 and both the 16a4u and 32a4u are included. Probably they're in the windows version too. On Thu, Feb 13, 2014 at 4:36 AM, David Fernandez wrote: > Hi there, > > Anybody knows if there is a script to create the io files for these two > processors? or

[avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Hi there, Anybody knows if there is a script to create the io files for these two processors? or if there is some procedure to create them? I guess I could go line by line trying to see if the definitions for atxmega16a4 match the ones from 16a4u, but then the thing is, do I need to add some

Re: [avr-gcc-list] avr-libc

Senthil Kumar Selvaraj schrieb: 2. What version of binutils are you using? 2.22.52.0.4 The common pattern I see in all the failures below is that hhi8(operand) is present at the faulty line. Looking at the CVS logs and diffs for binutils (gas/config/tc-avr.c), it looks like it was broken bet

Re: [avr-gcc-list] avr-libc

On Fri, Aug 03, 2012 at 11:32:37AM +0300, Kaan Akşit wrote: > 2012/8/3 Senthil Kumar Selvaraj > > > On Thu, Aug 02, 2012 at 04:06:19PM +0300, Kaan Akşit wrote: > > > Dear Senthil, > > > > > > Unfortunately, I still have the same error in avr-libc compilation :( > > Here > > > is the result of a s

Re: [avr-gcc-list] avr-libc

Hello, Yes, the same prefix should be used for binutils and gcc, and that is what the doc says ... Now I have a brand new gcc to play with ... I just hope I don't spend more time debugging the compiler than my project, but that is the fun part. Regards Francois On Thu, Aug 2, 2012 at 7:39 PM, R

Re: [avr-gcc-list] avr-libc

2012/8/3 Senthil Kumar Selvaraj > On Thu, Aug 02, 2012 at 04:06:19PM +0300, Kaan Akşit wrote: > > Dear Senthil, > > > > Unfortunately, I still have the same error in avr-libc compilation :( > Here > > is the result of a sample compilation after following your tutorial: > > The output below seems

Re: [avr-gcc-list] avr-libc

On Thu, Aug 02, 2012 at 04:06:19PM +0300, Kaan Akşit wrote: > Dear Senthil, > > Unfortunately, I still have the same error in avr-libc compilation :( Here > is the result of a sample compilation after following your tutorial: The output below seems ok, so I'm not sure why libc is failing. 1. I'm

Re: [avr-gcc-list] avr-libc

If you dont use the same --prefix for binutils and gcc you should be quite sure of what you are doing. At least ensure that the AVR as is earlier in the path than the standard as. hth Rolf Am 02.08.2012 um 16:04 schrieb Francois Lorrain : > Hello, > > I think there might be something goin

Re: [avr-gcc-list] avr-libc

Hello, I think there might be something going on (or I am doing the same mistake), after trying to create a recent version of the AVR compiler, I am getting : $ avr-gcc -v test.c Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/4.7.2/lto-wrapper Target: avr

Re: [avr-gcc-list] avr-libc

Dear Senthil, Unfortunately, I still have the same error in avr-libc compilation :( Here is the result of a sample compilation after following your tutorial: kaan@SAHILEVLERI ~ $ avr-gcc -mmcu=atmega8 -v -c test.c Using built-in specs. COLLECT_GCC=avr-gcc Target: avr Configured with: ../gcc-4.7.1

Re: [avr-gcc-list] avr-libc

On Wed, Aug 01, 2012 at 03:19:58PM +0300, Kaan Akşit wrote: > I am really confused because if I do not set any prefix during > configuration; both avr-gcc and avr-binutils will use /usr/local which > means default is not the supported way. > > So to give an example if I use prefix /usr/local for a

Re: [avr-gcc-list] avr-libc

I am really confused because if I do not set any prefix during configuration; both avr-gcc and avr-binutils will use /usr/local which means default is not the supported way. So to give an example if I use prefix /usr/local for avr-binutils, should I be using something outside of /usr/local ? For e

Re: [avr-gcc-list] avr-libc

On Wed, Aug 01, 2012 at 12:35:47PM +0300, Kaan Akşit wrote: > I am using below code to configure avr-gcc, I don't understand what is > wrong with it: > > ../configure --target=avr --mandir=/usr/share/man --datadir=/usr/share > --prefix=/usr/share/avr --enable-languages="c,c++" --disable-nls > --di

Re: [avr-gcc-list] avr-libc

I am using below code to configure avr-gcc, I don't understand what is wrong with it: ../configure --target=avr --mandir=/usr/share/man --datadir=/usr/share --prefix=/usr/share/avr --enable-languages="c,c++" --disable-nls --disable-libssp --with-dwarf2 --with-system-zlib --enable-version-specific-

Re: [avr-gcc-list] avr-libc

On Tue, Jul 31, 2012 at 05:09:44PM +0300, Kaan Akşit wrote: > I have exported the path, if I compile avr-gcc without export; it ends up > compiling without the previous warning and this time the below error > appears: > > Configuring in avr/libgcc > configure: creating cache ./config.cache > check

Re: [avr-gcc-list] avr-libc

Kaan Akşit schrieb: $ avr-gcc -mmcu=atmega8 -v -c demo.c Using built-in specs. COLLECT_GCC=avr-gcc Target: avr Configured with: ../configure --target=avr --mandir=/usr/share/man You still configure in the source tree which is not supported. Johann

Re: [avr-gcc-list] avr-libc

I have exported the path, if I compile avr-gcc without export; it ends up compiling without the previous warning and this time the below error appears: Configuring in avr/libgcc configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system typ

Re: [avr-gcc-list] avr-libc

I have also noticed during avr-gcc compile; there is this warning appearing from time to time: limits.h: present but cannot be compiled Kaan 2012/7/31 Kaan Akşit > I have export a path before I install avr-gcc. I noticed that I have set > PREFIX for avr-binutils as /usr but for avr-gcc it is /

Re: [avr-gcc-list] avr-libc

I have export a path before I install avr-gcc. I noticed that I have set PREFIX for avr-binutils as /usr but for avr-gcc it is /opt/toolchain/avr so I have recompiled everything from the scratch. Now it seems avr-libc is compiling! Thanks Senthil But now I receive this during the make process of a

Re: [avr-gcc-list] avr-libc

On Tue, Jul 31, 2012 at 03:45:33PM +0300, Kaan Akşit wrote: > Thank you Senthil, here is the result of the test.c > > kaan@SAHILEVLERI ~ $ cat demo.c > int main () { return 0; } > kaan@SAHILEVLERI ~ $ avr-gcc -mmcu=atmega8 -v -c demo.c > as -mmcu=atmega8 -mno-skip-bug -o demo.o /tmp/cc2pzgVI.s >

Re: [avr-gcc-list] avr-libc

as: tanınmayan seçenek: `-mmcu=atmega8' By the way, it stands for unknown option mmcu=atmega8 Kaan 2012/7/31 Kaan Akşit > Thank you Senthil, here is the result of the test.c > > kaan@SAHILEVLERI ~ $ cat demo.c > int main () { return 0; } > kaan@SAHILEVLERI ~ $ avr-gcc -mmcu=atmega8 -v -c demo.

Re: [avr-gcc-list] avr-libc

Thank you Senthil, here is the result of the test.c kaan@SAHILEVLERI ~ $ cat demo.c int main () { return 0; } kaan@SAHILEVLERI ~ $ avr-gcc -mmcu=atmega8 -v -c demo.c Using built-in specs. COLLECT_GCC=avr-gcc Target: avr Configured with: ../configure --target=avr --mandir=/usr/share/man --datadir=/

Re: [avr-gcc-list] avr-libc

On Tue, Jul 31, 2012 at 02:55:39PM +0300, Kaan Akşit wrote: > Dear all, > > I have tried the sample code under this link: > http://www.nongnu.org/avr-libc/user-manual/group__demo__project.html#demo_project_src > > and here is the output: > > kaan@SAHILEVLERI ~ $ avr-gcc -g -Os -mmcu=atmega8 -c d

Re: [avr-gcc-list] avr-libc

Hi, Are you sure you have avr binutils properly installed? From the assembler error messages, it looks like some other assembler (most likely the native one) is getting invoked instead of the AVR assembler. On my X86_64 machine, I get the same error if I try to assemble a file with IN and LD

Re: [avr-gcc-list] avr-libc

Dear all, I have tried the sample code under this link: http://www.nongnu.org/avr-libc/user-manual/group__demo__project.html#demo_project_src and here is the output: kaan@SAHILEVLERI ~ $ avr-gcc -g -Os -mmcu=atmega8 -c demo.c demo.c:17:22: fatal error: inttypes.h: No such file or directory compi

Re: [avr-gcc-list] avr-libc

Kaan Aks,it wrote: > Dear all, > > I have successfully installed avr-binutils, avr-gcc by compiling from the > source. Now it is time for me to compile avr-libc so that I can use the > complete AVR toolchain. But I have encountered an error during > configuration phase of avr-libc. Here is the con

[avr-gcc-list] avr-libc

Dear all, I have successfully installed avr-binutils, avr-gcc by compiling from the source. Now it is time for me to compile avr-libc so that I can use the complete AVR toolchain. But I have encountered an error during configuration phase of avr-libc. Here is the config.log of the avr-libc. I coul

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Joerg Wunsch schrieb: Users aren't supposed to use these attributes directly anyway. I am not in the position to tell users what they are supposed to do and what they are not supposed to do. Anyway, the compiler won't notice if a feature like interrupt or signal is used through a macro or API

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > Well, if a Linux programmer comes over and expects anything, ... That's not my point. My point is that the chosen name bears *neither* any relationship to what a "signal" in a microcontroller environment is (that would be a hardware signal, attaching to an IO pin), *no

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Joerg Wunsch schrieb: Georg-Johann Lay wrote: One hack would be that "interrupt" overrides/is stronger than "signal" and likewise for OS_task/OS_main. I don't like it much, in particular since the name "signal" does not mean anything to the casual embedded programmer, and it's something fairl

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > One hack would be that "interrupt" overrides/is stronger than "signal" > and likewise for OS_task/OS_main. I don't like it much, in particular since the name "signal" does not mean anything to the casual embedded programmer, and it's something fairly different than a "

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Joerg Wunsch schrieb: Georg-Johann Lay wrote: I just don't see a trick how to add "signal" only if NO_INTERRUPT is not specified. Neither do I. The compiler could be changed to handle it, of course. But I am no fan of trying to support mutually exclusive/contradicting things... One hack

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- > gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg > Wunsch > Sent: Wednesday, May 02, 2012 12:58 PM > To: avr-gcc-list@nongnu.org > Subje

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

"Weddington, Eric" wrote: > Only if we can deprecate the old names, otherwise we're going to > have the GCC maintainers ask us how many attribute names do we need! > ;-) We should at least maintain them for some period still, in order to decouple GCC's release process from avr-libc's. In other

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- > gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg > Wunsch > Sent: Tuesday, May 01, 2012 2:35 PM > To: avr-gcc-list@nongnu.org > Subject: R

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > I just don't see a trick how to add "signal" only if NO_INTERRUPT > is not specified. Neither do I. > The compiler could be changed to handle it, of course. > But I am no fan of trying to support mutually exclusive/contradicting > things... I wonder whether we should

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Weddington, Eric schrieb: Johann Lay AVR-LIbC's ISR-macros lead to confusing results for code like, e.g. #include #include void *p; ISR (ADC_vect, ISR_NOBLOCK) { char c[10]; p = c; } which resolves a.a. to void __vector_21 (void) __attribute__ ((signal,used,externally_visible))

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Jörg Wunsch > Subject: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK > > AVR-LIbC's ISR-macros lead to confusing results for code like, e.g. > > #include > #include > > void *p; > > ISR (ADC_vect, ISR_NOBLOCK) > { > char c[10]; >

[avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

AVR-LIbC's ISR-macros lead to confusing results for code like, e.g. #include #include void *p; ISR (ADC_vect, ISR_NOBLOCK) { char c[10]; p = c; } which resolves a.a. to void __vector_21 (void) __attribute__ ((signal,used,externally_visible)) __attribute__((interrupt)); Which state

Re: [avr-gcc-list] [avr-libc]: Timeline for #35407 ?

I will try to fix before March 11. Without new Avr-libc version. Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[avr-gcc-list] [avr-libc]: Timeline for #35407 ?

Is there a tentative timeline/version of AVR-Libc that comes with a fix for the following issue? http://savannah.nongnu.org/bugs/?35407 Would 1.8.1 (whenever it will be released) be a reasonable assumption? Johann ___ AVR-GCC-list mailing list AVR-G

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect On 13/01/2012 18:24, Weddington, Eric wrote: IMNSHO, Code space trumps all other concerns. Eric I don't agree with that. It's seldom that I run out of code space on AVR's - it's more of

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, January 13, 2012 12:28 PM > To: Weddington, Eric > Cc: Ruud Vlaming; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are > incorrect

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Weddington, Eric wrote: > >> >> Weddington, Eric wrote: >>> I agree with you except for one point: I don't want to *have* to do >>> a hack (-mint8) to have the compiler do the right thing. >> As already said it *changes the ABI*. The compiler will never know if >> different >> ABI is okay by stari

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefsareincorrect

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On > Behalf Of David Brown > Sent: Friday, January 13, 2012 10:48 AM > To: avr-gcc-list@nongnu.org > Subject: R

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On > Behalf Of David Brown > Sent: Friday, January 13, 2012 10:45 AM > To: avr-gcc-list@nongnu.org > Subject: R

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

On 13/01/2012 14:37, Ruud Vlaming wrote: On Thursday 12 January 2012, Weddington, Eric wrote: The problem that I have with -mint8 is: - it doesn't follow the standard - it breaks avr-libc (or rather, avr-libc isn't adapted to it) - people use it, because the backend hasn't been taught how to do

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

On 13/01/2012 18:24, Weddington, Eric wrote: IMNSHO, Code space trumps all other concerns. Eric I don't agree with that. It's seldom that I run out of code space on AVR's - it's more often that I want more effective code (which means slower clocks, less power, etc.). Experiences vary, a

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, January 13, 2012 7:59 AM > To: Weddington, Eric > Cc: Ruud Vlaming; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are > incorrect

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Weddington, Eric wrote: > > I agree with you except for one point: I don't want to *have* to do a > hack (-mint8) to have the compiler do the right thing. As already said it *changes the ABI*. The compiler will never know if different ABI is okay by staring at its crystal ball... ;-) ___

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefsareincorrect

> > The problem i have with the standard C is that it lacks a > > proper 8 bit arithmetic. That is why -mint8 comes in so > > handy, and produces very compact code. In many > > cases 8 bit are more than enough to do the job, but within > > the standard you are enforced to use a char (!) for nu

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, January 13, 2012 2:13 AM > To: Weddington, Eric > Cc: Joerg Wunsch; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are > incorrect >

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefsareincorrect

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On > Behalf Of Ruud Vlaming > Sent: Friday, January 13, 2012 6:38 AM > To: avr-gcc-list@nongnu.org > Subject: R

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

On Thursday 12 January 2012, Weddington, Eric wrote: > The problem that I have with -mint8 is: > - it doesn't follow the standard > - it breaks avr-libc (or rather, avr-libc isn't adapted to it) > - people use it, because the backend hasn't been taught how to do the > right thing. > > The thing is

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

> -Original Message- > From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On > Behalf Of Joerg Wunsch > Sent: Friday, January 13, 2012 12:35 AM > To: avr-gcc-list@nongnu.org > Subje

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

On 13/01/2012 12:56, Georg-Johann Lay wrote: David Brown wrote: Why not say -mint8 is dead? [...] Then "-mint8" can be marked "deprecated" in gcc 4.7, and removed in the future. I think the -mint8 can be removed immediately without deprecating it beforehand. -mint8 is badly broken since 4.5

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

David Brown wrote: > Why not say -mint8 is dead? [...] > > Then "-mint8" can be marked "deprecated" in gcc 4.7, and removed in the > future. I think the -mint8 can be removed immediately without deprecating it beforehand. -mint8 is badly broken since 4.5 anyways. Specifying -mint8 will run into

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

On 12/01/2012 21:09, Weddington, Eric wrote: -Original Message- From: Georg-Johann Lay Sent: Thursday, January 12, 2012 10:55 AM To: Weddington, Eric Cc: Joerg Wunsch; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect sizeof

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Weddington, Eric wrote: > >> From: Georg-Johann Lay >> Weddington, Eric schrieb: sizeof(double) = 4 also breaks the standard... >>> Hence, one of the reasons to have correct doubles added to the >>> backend. >> Would a patch for 4.7 be supported by avr maintainers? >> >> Patch would look like

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Volker Kuhlmann wrote: > Your analysis tool is correct in not having uintX_t predefined. K&R > quite clearly says that they are defined in a lib header file. Note that "R" in the K&R meanwhile died, and I doubt he contributed much to the C99 standard. "K&R", in terms of standardizing C, usually

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

> -Original Message- > From: Georg-Johann Lay > Sent: Thursday, January 12, 2012 2:55 PM > To: Weddington, Eric > Cc: Joerg Wunsch; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are > incorrect > > Weddington, E

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Weddington, Eric schrieb: sizeof(double) = 4 also breaks the standard... Hence, one of the reasons to have correct doubles added to the backend. Would a patch for 4.7 be supported by avr maintainers? Patch would look like: - depend DOUBLE_TYPE_SIZE, LONG_DOUBLE_TYPE_SIZE on short-double -

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

> -Original Message- > From: Georg-Johann Lay > Sent: Thursday, January 12, 2012 10:55 AM > To: Weddington, Eric > Cc: Joerg Wunsch; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs > areincorrect > > > size

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

Weddington, Eric wrote: > Ok, so there are historical reasons why we (avr-libc maintainers) did it > that way. Today, it may be different. The historical reason might have been that some guys were unsure about the implementation and the implementation (avr-gcc) is not well documented: You will hav

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs > areincorrect > > Your analysis tool is correct in not having uintX_t predefined. K&R > quite clearly says that they are defined in a lib header file. Your tool > is also correct in not dealing with pr

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

On Thu 12 Jan 2012 07:00:03 NZDT +1300, Paul McClean wrote: > Unfortunately the static analysis tool I am using isn't aware of > uint32_t, etc. Instead it requires to be told what are the sizes of the > standard types on the target and it will then check that there are no > dangerous casts, compar

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

r-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs > areincorrect > > Joerg Wunsch schrieb: > > As Georg-Johann Lay wrote: > > > >>As fas as I know the only reason why avr-libc used mode attribute is to > >>factor out impa

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

As Georg-Johann Lay wrote: > There's absolutely no rationale for using mode attribute as sizeof(long) > is defined by the implementation and won't change at will. https://savannah.nongnu.org/patch/?3782 introduced the mode attributes. -- cheers, J"org .-.-. --... ...-- -.. .

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: As fas as I know the only reason why avr-libc used mode attribute is to factor out impact of -mint8, ... No, our previous definitions were -mint8 clean, AFAICT. It just looked more elegant to use GCC's mode attributes to ensure certain bit wi

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

r-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect As David Brown wrote: > But where is the harm in having uint32_t typedef'ed as: > unsigned long int __attribute__ ((__mode__(__SI__))) > > Is there any hidden cost or di

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

As David Brown wrote: > But where is the harm in having uint32_t typedef'ed as: > unsigned long int __attribute__ ((__mode__(__SI__))) > > Is there any hidden cost or disadvantage here that I (and others) are > not aware of? No, it could be done. I just don't think it's a cool idea to wor

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Joerg Wunsch schrieb: "Paul McClean" wrote: The standard C does not make *any* claim about the actual number of bits in an `unsigned long' data type, it only specifies a *minimum* number of bits (indirectly, by telling a minimal magnitude value for LONG_MIN, LONG_MAX, and ULONG_MIN, respectivel

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

On 11/01/2012 08:21, Joerg Wunsch wrote: "Paul McClean" wrote: Can anyone explain why the GCC instructions are used in place of the typical definition? Because the mode names are GCC's equivalent for specifying a particular number of bits. Could it be expressed as: unsigned long __attribut

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

"Paul McClean" wrote: > Can anyone explain why the GCC instructions are used in place of the > typical definition? Because the mode names are GCC's equivalent for specifying a particular number of bits. > Could it be expressed as: > unsigned long __attribute__ ((__mode__ (__SI__))) > with both

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

January 2012 19:28 To: Paul McClean Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect > However lines 125 and 126 define int32_t and uint32_t as signed > int and unsigned int respectively. What about the rest of that lines? unsigned int

  1   2   >