On Wed, 15 May 2024 at 07:49, Wolfgang Hospital
wrote:
>
> Dear all,
>
> G-J Lay has been kind enough to turn my whine about __udivmodqi4 into a bug
> report and handle that; I tried to follow suit reporting further strict
> improvements (NO resource used more, at least one used less).
> While
On 9 April 2015 at 01:15, Bill Westfield wrote:
> Is there a way to get gcc to dump the settings of all the parameters
> and option settings after it's done parsing the command line?
That would be -fverbose-asm combined with -S or --save-temps;
this dumps the settings in the assembly output.
An
On 25 November 2014 at 13:57, Ivaylo Ganchev
wrote:
> As a side-note the pgmspace.h includes also . I am not sure
> whether the correct one is charged. To be sure I also make an explicit
> statement (#include "/usr/lib/gcc/avr/4.7.2/include/stddef.h"). What is
This seems to indicate that you are
On 17 November 2014 17:17, Georg-Johann Lay wrote:
> as a test case which works both for C and C++. The C++ front fails in
> applying a similar type demotion like the C front,
Well, duh, that's because it's a different language.
>
>
> Is there a solution that is more reliable than combine? Cur
On 8 November 2014 00:32, Szikra István wrote:
> Hi everyone!
>
> My problem in sort: I’m getting
> in r24, 0x18
> ldi r25, 0x00
> andir24, 0xEF
> out 0x18, r24
> instead of
> cbi 0x18, 4
> .
>
> I’m trying to write efficient modern C/C+
On 8 November 2014 00:32, Szikra István wrote:
> Unfortunately GCC support for AVR (among other things) is not always
> flawless. And it changes from versions to version (and not always for the
> better).
regression tests can help to catch instances where the compiler looses
functionality.
I'm
On 14 October 2014 12:36, Erik Christiansen wrote:
> On 14.10.14 12:43, Georg-Johann Lay wrote:
>> Issuance of calls to functions as registered by atexit() is located in
>> section .fini6a. As the current linker description does not handle that
>> section
>
> It's a bit late for this case, now th
On 14 October 2014 11:43, Georg-Johann Lay wrote:
> atexit.c has several issues which are fixed by the patch below:
>
>
> i)
> Issuance of calls to functions as registered by atexit() is located in
> section .fini6a. As the current linker description does not handle that
> section it's treated as
On 25 September 2014 21:11, Joerg Wunsch wrote:
> As Christian Schmidt wrote:
>
>> Is it fair to conclude that the ~
>> operator, applied to an unsigned char, does produce an int as output
>> instead of the input type?
>
> Yes, this is exactly what the C standard promotion rules require.
>
> Well,
