does not reside
in read-only memory. And then, as Richi said, this may be a de-optimization
if you consider the costs of dirtying a cache line conditionally or always
(or, for a more dramatic case, triggering a page fault or not).
Alexander
ations that
> could be allowed by default?
-fallow-store-data-races guards transforms that we know to be incorrect
for source code that may become a part of a multithreaded program.
Are you asking about something else?
Alexander
Introducing racing loads is generally not harmful, see note 14.
Alexander
On Tue, 24 Dec 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> > Well, the first paragraph in your initial mail was talking very explicitly
> > about making a tailcall from the wrapper, so I guess the goalpost has moved.
>
> Uhm, I meant a tailcall from the tra
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
> >> Does this work on all primary GCC targets?
> >
> > Yes? I'm not sure why you think it might not work. What are your
> > concerns?
>
> Targets not setting up REGISTER_NAMES,
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
>
> > On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> >
> >> I would like to provide a facility to create wrapper functions without
> >> lots of argument shuffling. To ach
^~~:
This is the only approach I'm aware of, apart of generating wrappers
in asm (speaking of, is there some reason that wouldn't work for you?).
HTH
Alexander
; Any idea how to drop that branch again from the main gcc.gnu.org repo?
You have to use the name of the branch in the remote repo, "python-formatting":
git push --delete origin python-formatting
(or using the colon syntax:)
git push origin :python-formatting
Alexander
at the source, but they do not issue the warning if the value is exactly
representable in the format (but they warn if it was implicitly cast from an
integer, like in 'x == 0', which is probably a bug). They also suppress the
warning in some other cases, e.g. for 'x == x'.
Alexander
in
> > tree_node_structure_for_code, at tree:527"
> >
> > How should I approach reporting this to get it fixed?
>
> It sounds you might got faulty memory in your system.
Allan, what CPU is that on? If Intel 13th or 14th gen, that's not entirely
unexpected, unfortunately, due to voltage management issues (or manufacturing,
on some earlier samples).
Alexander
rhaps somebody remembers where it was (I'm thinking Bugzilla) and could point
me to it? My attempts to search for it aren't turning anything up so far.
If someone knows what semantics GCC implements, that also would be welcome.
Thank you.
Alexander
On Mon, 8 Apr 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> >> There is quite a bit of variance in how the kernel is entered. On
> >> x86-64, one once popular mechanism is longer present in widely-used
> >> kernels.
> >
> > I assu
s
the __kernel_vsyscall entrypoint, which provides whichever of
{ int 0x80, sysenter, syscall } methods is available and fastest.
Or am I missing something?
Alexander
uiltin_constant_p(nonzero)) {
res = -1;
asm("bsf %1, %0" : "+r"(res) : "rm"(x));
} else if (nonzero) {
asm("bsf %1, %0" : "=r"(res) : "rm"(x));
} else {
res = -1;
}
return res;
}
Does it work for you?
HTH
Alexander
which is
currently available via the Wayback Machine, but not its original URL:
https://web.archive.org/web/20230316072811/http://embed.cs.utah.edu/csmith/using.html
It was written by the developers of Csmith.
Alexander
}
the narrowing conversion is represented with NOP_EXPR, and it is definitely
not a no-op.
Does some clear distinction remain, and is it possible to clarify the
definitions?
Thanks.
Alexander
cdir)/libgcov.h
> > $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c
> >
> > It looks like this is done to emulate -Wl,--gc-sections without separate
> > source files. Unfortunately, this is all built unconditionally.
>
> Hmm, so why's it then referenced and not "GCed"?
On MinGW the corresponding .o file is not unpacked by the linker from libgcov.a
when fork is not referenced, so it used to work fine. The problem is that now
building the .o fails due to undeclared fork.
> The classical "solution" is to make the reference weak via sth like
>
> extern typeof(fork) fork () __attribute__((weak));
This won't help here since fork is undeclared. Using __builtin_fork, as
mentioned in adjacent sub-thread, should work.
Alexander
is compiled.
>
> Makes sense. The target-specific macro `_WIN32` serves that purpose.
>
> However `fork()` doesn't actually exist there, and linking should indeed fail.
> Maybe `__gcov_fork()` shouldn't be defined at all.
A possible stop-gap solution is using __builtin_fork() instead.
Alexander
example off-hand, since apart from FMA
fused operations are rarely available in instruction sets.
Alexander
ound statements (!= blocks).
Thanks for the clarification. Let me note that the standard somehow
decided to make out-of-place pragma a (compile-time) UB rather than
a constraint violation, leaving us free to make it work for blocks
(or launch Nethack).
Alexander
ult when x is so large that 'x + x' is
not representable (exponent would overflow), but that's exactly what
contraction is about?
Alexander
hard to implement for C. But I was somewhat discouraged by the lack of
front-end maintainers reaction to the patch implementing the =standard,
so I didn't pursue that.
The hardest part would be popping the pragma state when leaving a block,
which didn't seem difficult (at least for C).
Alexander
quirk about sNaNs and qNaNs.
Sorry, do you mean contracting 'x + x - x' to 'x'? That is not allowed
due to different result and lack of FP exception for infinities.
Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
Alexander
Hi Florian,
On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
>
> > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > several packages had test suite failures because x86-64 suddenly gained
&g
a worked example where -ffp-contract=fast
caused a correctness issue in a widely used FOSS image processing application
that was quite hard to debug.
Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
make the change, so SPEC scores won't be affected.
Thanks.
Alexander
essages are not available there)
Alexander
nd on the expected usefulness?
Alexander
ame way?
Another one is -Wpointer-arith (pointer arithmetic on 'void *').
Alexander
e that is the
> signed or unsigned type corresponding to the effective type of the object
The standard allows aliasing, but not assigning pointers without a cast.
This is valid:
unsigned x;
int *p = (void *)&x;
*p = 0;
This is not valid (constraint violation):
unsigned x;
int *p = &x;
In GCC this is diagnosed under -Wpointer-sign:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
Alexander
* add documentation to the GCC site, how to build GCC with PGO
optimizations
* (if GCC community provides prebuilt gcc binaries) use PGO for the
prebuilt binaries. E.g. Clang and rustc already uses this approach.
Any feedback is appreciated.
Thanks in advance!
--
Best regards,
Alexander
, but yes, it's
> portable.
I don't see why you'd need that in "every public header". Public headers
should be so simple they would have no need to check C version at all, no?
Alexander
seful for libraries, which might for example require
> C99 or C11 to work. They would be able to specify -minstd=c11 in their pc(5)
> file (for use with pkgconf(1)).
There's already a standard, portable way to check:
#if __STDC_VERSION__ < 201710
#error C17 required
#endif
Alexander
ing
-Warray-bounds=2 -Werror=array-bounds=1
(errors for most certain OOB accesses, warnings otherwise).
Alexander
7;s the other way around).
Opinions? Does anybody envision problems with going the DWIM way?
Thanks.
Alexander
[1]
https://inbox.sourceware.org/gcc-patches/2552ab22-916f-d0fe-2c78-d482f6ad8...@lauterbach.com/
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088#c5
#x27;m probably missing something, why autoconf
> can't use that idiom instead. But perhaps the (historic?) reasons why it
> couldn't be used are gone now?
Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
and thus no symbol reference remains in the resulting assembly.
Alexander
oken with a few lists,
as clicking on a thread results in a 404 page, e.g. any top link from
https://inbox.sourceware.org/gcc-bugs/
Alexander
g it up so it doesn't die indexing the codebase
(e.g. adding the entire toplevel directory probably won't work: it will
try to index the testsuites).
FWIW, CLion documentation shows how to select GNU coding style, but as
above, that's not the main worry:
https://www.jetbrains.com/help/clion/predefined-code-styles.html
Alexander
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> On 20/07/2022 13:41, Alexander Monakov wrote:
> > On Wed, 20 Jul 2022, Sebastian Huber wrote:
> >
> >> How does Ada get its default TLS model?
> > You shouldn't need to do anything special, GCC automatically sel
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
Alexander
From: Vincent MAILHOL
Date: Wed, 27 Apr 2022 11:58:58 +0900
> + Alexander Lobakin
I was okay even with the previous solution to modify
GENMASK_INPUT_CHECK() and this one is fine to me as well.
The presense of warnings on W=1 doesn't mean we shouldn't fix W=12
etc. Especially when
n future)
> conversion specifier.
>
> (But I am only guessing.)
%p (not %n) allows the pointer to escape.
Alexander
treat them specially.
Another example is mips64, where even non-PIC PLT is special (but looks like
LLVM does not do any tailcalls on mips64 at all).
Alexander
rmal scheduling), not control speculation.
I think GCC may have correctness issues with ia64-style control speculation
before register allocation, but I can't think of a reason why check-free loads
would pose a problem.
Alexander
y
> the current C behavior is what OpenCL specifies.
Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
opposite (the code would fail to compile):
6.2.1
Implicit Conversions
[...]
Implicit conversions between built-in vector data types are disallowed.
Alexander
an "imaginary" empty GOT somewhere, just to have a stable anchor
against which to resolve GOTOFF relocations)
Please consider filing a bug against binutils on sourceware.org, this looks
like a QoI issue in the linker: it should emit a diagnostic rather than
non-sensical code.
Alexander
tion-defined signal may be raised if the result
would not fit in int32_t, but GCC defines the behavior as bitwise truncation
in all cases.
Alexander
es undefined behavior.
The x86 'idiv' instruction, however, will raise a divide error if the result
does not fit in a register, so e.g. dividing INT64_MAX by 1 would trap.
Alexander
From: Richard Biener
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie
Cc: Alexander Yermolovich ; Jakub Jelinek ;
Mark Wielaard ; gcc@gcc.gnu.org ;
ikud...@accesssoftek.com ; mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On Thu
From: David Blaikie
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
From: David Blaikie
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
From: David Blaikie
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
s just asking to end up with debug level that might not be
what user expects.
Thank You
Alex
From: David Blaikie
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener
Cc: Jakub Jelinek ; Mark Wielaard ;
gcc@gcc.gnu.org ; ikud...@accesssoftek.com
Hello
On llvm side of compiler world there has been work done by Igor Kudrin to
enable DWARF64.
I am trying to add a flag to Clang to enable DWARF64 generation.
https://reviews.llvm.org/D90507
In review David Blaikie pointed out that there has been a discussion on what to
call this flag:
https:
On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > No, this is not how LEA operates. It needs a memory input operand. The
> > > above will report "operand type mismatch for 'lea'" error.
>
ith lea is
avoiding base+offset computation outside the asm. If you're okay with one
extra register tied up by the asm, just pass the address to the asm directly:
void foo(__seg_fs int *x)
{
asm("# %0 (%1)" :: "m"(x[1]), "r"(&x[1]));
asm("# %0 (%1)" :: "m"(x[0]), "r"(&x[0]));
}
foo:
leaq4(%rdi), %rax
# %fs:4(%rdi) (%rax)
# %fs:(%rdi) (%rdi)
ret
Alexander
On Thu, 5 Nov 2020, Uros Bizjak wrote:
> On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote:
> >
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > What is the usecase for stripping the address space for asm operands?
> > >
> >
%0" :: "m"(strip_as(x[1])));
}
yields
foo:
# %fs:4(%rdi)
# 4(%rdi)
ret
I think a clean future solution is adding a operand modifier that would
print the memory operand without the segment prefix.
Alexander
tand the kernel wants to pass qualified
lvalues to inline assembly to get
lea , %fs:
LEA without the %fs will produce the offset within the segment, which
you can obtain simply by casting the pointer to intptr_t in the first place.
Alexander
p only covers about 46-48% of overall time.
High count on the initial ldur instruction could be explained if the loop
is not entered by "fallthru" from the preceding block, or if its backedge
is mispredicted. Sampling mispredictions should be possible with perf record,
and you may be able to check if loop entry is fallthrough by inspecting
assembly.
It may also be possible to check if code alignment matters, by compiling with
-falign-loops=32.
Alexander
ot; the result as needed towards
higher ILP or whatever the concrete machine prefers :)
Alexander
ryone is on the same page about that.
I also suspect that the dramatic slowdown has to do with the extra branch.
Your CPU might have some specialized counters for branch prediction, see
'perf list'.
Alexander
On Mon, 24 Aug 2020, Richard Biener via Gcc wrote:
> Whether or not the conditional branch sequence is faster depends on whether
> the branch is well-predicted which very much depends on the data you
> feed the isWhitespace function with but I guess since this is the
> c == ' ' test it _will_ be a
On 24.06.2020 15:53, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote:
>> Add 'verbose' plugin parameter for stackleak gcc plugin.
>> It can be used for printing additional info about the kernel code
>> instrumentation.
>&
On 24.06.2020 15:52, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote:
>> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
>> avoid unneeded instrumentation.
>>
>> Signed-off-by: Alexander Popov
>
&g
n grsecurity blog
https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction
Signed-off-by: Alexander Popov
Acked-by: Miguel Ojeda
---
include/linux/compiler_attributes.h| 13 ++
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins |
eak_plugin-verbose
Signed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 47 +++---
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index a18b0d4af456..48e141e07
Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c
to avoid unneeded instrumentation.
Signed-off-by: Alexander Popov
---
arch/arm64/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/k
Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
avoid unneeded instrumentation.
Signed-off-by: Alexander Popov
---
arch/arm/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index d3c9f03
ion during kernel building.
I would like to thank Alexander Monakov for his
advisory on gcc internals.
This patch series was tested for gcc version 4.8, 5, 6, 7, 8, 9, and 10
on x86_64, i386 and arm64.
That was done using the project 'kernel-build-containers':
https://github.com/a1
There is no need to try instrumenting functions in kernel/stackleak.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
Acked-by: Kees Cook
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel
VDSO is built without plugin flags. So it's ok.
Best regards,
Alexander
On 10.06.2020 23:03, Kees Cook wrote:
> On Wed, Jun 10, 2020 at 06:47:14PM +0300, Alexander Popov wrote:
>> On 09.06.2020 21:46, Kees Cook wrote:
>> The inline asm statement that is used for instrumentation is arch-specific.
>> Trying to add
>> asm volatile("ca
On 09.06.2020 21:47, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:55PM +0300, Alexander Popov wrote:
>> Add 'verbose' plugin parameter for stackleak gcc plugin.
>> It can be used for printing additional info about the kernel code
>> instrumentation.
>>
On 09.06.2020 21:46, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:54PM +0300, Alexander Popov wrote:
>> Let's improve the instrumentation to avoid this:
>>
>> 1. Make stackleak_track_stack() save all register that it works with.
>> Use no_caller_saved_regis
On 09.06.2020 21:39, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 06:23:38PM +0300, Alexander Popov wrote:
>> On 04.06.2020 17:01, Jann Horn wrote:
>>> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov wrote:
>>>> Some time ago Variable Length Arrays (VLA) were removed fr
On 10.06.2020 10:30, Will Deacon wrote:
> On Tue, Jun 09, 2020 at 12:09:27PM -0700, Kees Cook wrote:
>> On Thu, Jun 04, 2020 at 02:58:06PM +0100, Will Deacon wrote:
>>> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
>>>> Don't try instrume
On 09.06.2020 22:15, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote:
>> In this patch series I collected various improvements of the stackleak
>> gcc plugin.
>
> Thanks!
>
>> Alexander Popov (5):
>> gcc-plugins/
On 04.06.2020 17:01, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov wrote:
>> Some time ago Variable Length Arrays (VLA) were removed from the kernel.
>> The kernel is built with '-Wvla'. Let's exclude alloca() from the
>> instrumentation
On 04.06.2020 17:25, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov wrote:
>> On 04.06.2020 17:14, Jann Horn wrote:
>>> Maybe at some point we should replace exclusions based on
>>> GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
>&g
On 04.06.2020 17:14, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:58 PM Will Deacon wrote:
>> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
>>> Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
>>> Otherwise that can cau
Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
---
arch/arm64/kernel/vdso/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
eak_plugin-verbose
Signed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 31 +-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index 0769c5b9156d..19358712d
There is no need to try instrumenting functions in kernel/stackleak.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/Makefile b/kernel
;t use alloca().
Signed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 51 +++---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index cc75eeba0be1..1ecfe50d0bf5 1
e unneeded stackleak instrumentation for some
files.
I would like to thank Alexander Monakov for his
advisory on gcc internals.
This patch series was tested for gcc version 4.8, 5, 6, 7, 8, 9, and 10
on x86_64, i386 and arm64.
That was done using the project 'kernel-build-containers':
n grsecurity blog
https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction
Signed-off-by: Alexander Popov
---
include/linux/compiler_attributes.h| 13 ++
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins | 2 +
scripts/gcc-plugins
tml
I'm surprised it's an issue for you: normally your email client
would transform quoted-printable and copying would do the right thing
(i.e. select actual patch contents, without whitespace munging).
Are you trying to copy from the raw message representation?
Alexander
ory with the ideas in your previous paragraph.
I agree though, CLOBBER-as-lifetime-end makes sense and does not
call for a replacement.
Thanks.
Alexander
an "experimental" topic that may be interesting for students.
What do you think?
Thanks.
Alexander
teral
for example, but triggering under-counting is trickier.
Petr, please see https://gcc.gnu.org/onlinedocs/gcc/Size-of-an-asm.html
for some more discussion.
Alexander
7;t it be better to load them as word and split them at the register
> level?
The question is not entirely clear to me, but usually the answer is that
it depends on the microarchitecture and details of the computations that
need to be done with loaded values. Often you'd need more than one instruction
to "split" the wide load, so it wouldn't be profitable.
Alexander
rn a blind
> eye to such minor non-conformance.
In that case can we simply say that both 'committed' and 'COMMITTED' are okay,
if we know glibc doesn't follow that rule and anticipate we will not follow
it either?
Thanks.
Alexander
x27; it will be the human typing that out, and
it makes little sense to require people to meticulously type that out in caps.
Especially when the previous practice was opposite.
Thanks.
Alexander
-nodefaultlibs next to -nostartfiles in its Makefile, and
write a trivial loop in place of __builtin_strlen.
Alexander
/tc-i386.c;h=d0b8f2624a1885d83d2595474bfd78ae844f48f2;hb=HEAD#l1441
>
> I'm not sure how worthy would it be to implement that?
Huh? Surely the right move would be to ask Binutils to expose that via
a new pseudo-op, like .balign but requesting a specific space rather
than aligning up to a boundary.
Alexander
t;
> Yes. But last I tried, optimizing that for > 1 alignment is problematic
> because that information often doesn't make it down to the target code even
> though it is documented to do so.
Thanks, indeed this memcpy solution is not so well suited for that.
Alexander
e new documentation promises a more
sensible approach)
In portable code one can also use memcpy to move unaligned data, the compiler
should translate it like an unaligned load/store when size is a suitable
constant:
int val;
memcpy(&val, ptr, sizeof val);
(or __builtin_memcpy when -ffreestanding is in effect)
Alexander
d alignment on
a typedef'ed scalar type goes way earlier than gcc-9)
Alexander
ice here in how I may contribute
would be much appreciated.
вт, 23 июл. 2019 г. в 19:21, Jonathan Wakely :
> Sorry for the late reply that wasn't "tomorrow".
>
> On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote:
> >
> > Hi there! I hope, this message will g
say explicitly, but that was meant more as a remark to IPA
maintainers: currently in GCC "address taken" implies "address significant",
so "address not significant" would have to be a new attribute, or a new decl
bit (maybe preferable for languages where function addresses are not significant
by default).
Alexander
1 - 100 of 285 matches
Mail list logo
