Hey.
Am 12.05.2020 um 13:29 schrieb Florian Weimer:
Would you use it if switching from -fno-exceptions to this new
approach resulted in an immediate 20% code size increase, without
actually using the new error handling feature at all? What about
10%?
I don't think that it will be that much.
W
Am 12.05.2020 um 11:44 schrieb Freddie Chopin:
Would you use it if switching from -fno-exceptions to this new
approach
resulted in an immediate 20% code size increase, without actually
using
the new error handling feature at all? What about 10%?
I don't think that it will be that much. I ag
Hey.
Am 11.05.2020 um 15:59 schrieb Thomas Neumann via Gcc:
In a way I am disagreeing with the paper, of course, in that I propose
to make the existing exception mechanism faster instead of inventing a
new exception mechanism. But what I agree on with P0709 is that it is
unfortunate that many pr
Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
[..] as the
alternative would be dropping the AVR port.
Shouldn't that work be sponsored by Microchip (or whoever currently owns
AVR)? Arduino Inc. might also be highly interested in continued
AVR-support.
Cheers
Morty
--
Redheads Ltd. Sof
Hey,
a pattern I see quite often in embedded libraries is to access an array
byte wise and shift the bits as needed (as this fixes endianness and
alignment issues). If I read two consecutive bytes and left-shift the
second by 8, I'd expect the compiler to optimize this to a word read on
a x64
Hey,
you can use Dmitry's solution at compile-time, too. "-D__LINE__={int
dontUseLine[-1];}"*.
This will most likely trigger an parse-error, because an int is
expected. And if the code does parse, it will fail at the array-length
being -1. You'll still might need to turn off some warning, becau
Hey.
Am 25.03.2019 um 13:36 schrieb Moritz Strübe:
> I have the following code:
> --
> #include
> #ifdef UN
> #define UNLIKELY(x) __builtin_expect((x),0)
> #else
> #define UNLIKELY(x) (x)
> #endif
>
> float a = 66;
>
> int test (float b,
Hi,
I have an issue with the optimization options. We are on an stm32 and it
only has a prefetcher, but no cache. Thus it's nice to have linear
default path. For example, we use __builtin_expect in our asserts. Yet
it seems that this does not work when using -Os. I confirmed that this
is not
Hey.
Am 20.03.2019 um 18:36 schrieb Andrew Haley:
> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>> Ok, I played around a bit. Interestingly, if I set
>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
>> compiler detects that it will always trap, and optimizes th
Hey.
Am 20.03.2019 um 15:26 schrieb Christophe Lyon:
You can -fsanitize-undefined-trap-on-error, which doesn't increase size too
much, it is less user-friendly, but still should catch the UB.
Wouldn't this fail to link? I thought the sanitizers need some runtime
libraries which are only avail
Hey.
Am 11.03.2019 um 12:17 schrieb Jakub Jelinek:
On Mon, Mar 11, 2019 at 11:06:37AM +, Moritz Strübe wrote:
On 11.03.2019 at 10:14 Jakub Jelinek wrote:
You could build with -fsanitize=undefined, that would tell you at runtime you
have undefined behavior in your code (if the SingleDiff
On 11.03.2019 at 10:14 Jakub Jelinek wrote:
> You could build with -fsanitize=undefined, that would tell you at runtime you
> have undefined behavior in your code (if the SingleDiff has bit ever 0x20
> set).
Yes, that helps. Unfortunately I'm on an embedded system, thus the code
size increase is
Hey,
I have the following code:
#include
void LL_ADC_SetChannelSingleDiff(uint32_t * val, uint32_t Channel,
uint32_t SingleDiff)
{
*val = (*val & (~(Channel & 0x7U))) | ((Channel & 0x7U ) &
(0x7U << (SingleDiff & 0x20U)));
}
void test(uint32_t * testvar) {
LL_ADC_SetCha
13 matches
Mail list logo
