search for: fdelet

...hat could, in some situations, run faster if code or data could be located at address zero. I don't know whether this applies to other embedded chips. Despite the name, the flag actually has rather straightforward semantics > from the compiler's perspective. From the gcc docs for > -fdelete-null-pointer-checks: "Assume that programs cannot safely > dereference null pointers, and that no code or data element resides at > address zero." (-fno-delete-null-pointer-checks is the opposite.) > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. >...

...M Friedman, Eli > <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: > > > Despite the name, the flag actually has rather straightforward > semantics > > from the compiler's perspective.  From the gcc docs for > > -fdelete-null-pointer-checks: "Assume that programs cannot safely > > dereference null pointers, and that no code or data element > resides at > > address zero."  (-fno-delete-null-pointer-checks is the opposite.) > > Ah, now that's quite a bit more palata...

...optimizations (probably as dictated by > the ones that have bitten someone who wrote bad code recently and was > grumpy enough about it to complain at us). Despite the name, the flag actually has rather straightforward semantics from the compiler's perspective.  From the gcc docs for -fdelete-null-pointer-checks: "Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero."  (-fno-delete-null-pointer-checks is the opposite.) -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is...

...r <t.p.northover at gmail.com> wrote: On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli <efriedma at codeaurora.org> > wrote: > Despite the name, the flag actually has rather straightforward semantics > > from the compiler's perspective. From the gcc docs for > > -fdelete-null-pointer-checks: "Assume that programs cannot safely > > dereference null pointers, and that no code or data element resides at > > address zero." (-fno-delete-null-pointer-checks is the opposite.) > > Ah, now that's quite a bit more palatable. I really should...

...<efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >> >> > Despite the name, the flag actually has rather straightforward >> semantics >> > from the compiler's perspective.  From the gcc docs for >> > -fdelete-null-pointer-checks: "Assume that programs cannot safely >> > dereference null pointers, and that no code or data element >> resides at >> > address zero."  (-fno-delete-null-pointer-checks is the opposite.) >> >> Ah, now that's qui...

...rrors * EXPORT_SYMBOL of inline functions However, there are some things in Clang/LLVM which also need to be addressed in order to make a Clang compiled Linux Kernel possible. Amongst other things these are: * The Linux kernel currently uses compiler flags which are unsupported in Clang: * -fdelete-null-pointer-checks * --fno-inline-functions-called-once * --Wno-unused-but-set-variable vs --Wno-unused-variable (GCC 4.6) * --mabi=aapcs-linux (Bug 11326) * Clang also reports errors for redefinitions of posix functions used in Linux kernel. It should be possible to suppress this. The...

> Despite the name, the flag actually has rather straightforward semantics > from the compiler's perspective. From the gcc docs for > -fdelete-null-pointer-checks: "Assume that programs cannot safely > dereference null pointers, and that no code or data element resides at > address zero." (-fno-delete-null-pointer-checks is the opposite.) Ah, now that's quite a bit more palatable. I really should have read the docs...

...t; wrote: > > > On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli <efriedma at codeaurora.org> >> wrote: > > > Despite the name, the flag actually has rather straightforward semantics >> > from the compiler's perspective. From the gcc docs for >> > -fdelete-null-pointer-checks: "Assume that programs cannot safely >> > dereference null pointers, and that no code or data element resides at >> > address zero." (-fno-delete-null-pointer-checks is the opposite.) >> >> Ah, now that's quite a bit more palatable....

On Wed, Apr 18, 2018 at 3:54 PM Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Despite the name, the flag actually has rather straightforward semantics > > from the compiler's perspective. From the gcc docs for > > -fdelete-null-pointer-checks: "Assume that programs cannot safely > > dereference null pointers, and that no code or data element resides at > > address zero." (-fno-delete-null-pointer-checks is the opposite.) > > Ah, now that's quite a bit more palatable. I really should...

On 18 April 2018 at 18:13, Manoj Gupta via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Therefore, I would like to implement support for this flag (maybe with a > different name), I'd suggest -mdo-what-i-mean; the whole idea is horribly underspecified, and basically rips up the LangRef in favour of a nebulous set of good and bad optimizations (probably as dictated by the ones that

...ctions > > However, there are some things in Clang/LLVM which also need to be > addressed in order to make a Clang compiled Linux Kernel possible. > Amongst other things these are: > > * The Linux kernel currently uses compiler flags which are unsupported > in Clang: > * -fdelete-null-pointer-checks > * --fno-inline-functions-called-once > * --Wno-unused-but-set-variable vs --Wno-unused-variable (GCC 4.6) > * --mabi=aapcs-linux (Bug 11326) > * Clang also reports errors for redefinitions of posix functions used in > Linux kernel. It should be possibl...

On Sep 6, 2009, at 4:01 PM, Török Edwin <edwintorok at gmail.com> wrote: > On 2009-09-06 20:52, Bill Wendling wrote: >> The problem he's facing here isn't necessarily one of correctness. >> He's dealing with undefined behavior (at least in C code). There are >> no guarantees that the compiler will retain a certain semantic >> interpretation of an

...m_dev/clang/include -Itools/clang/include -Iinclude -I/sw/src/clang_llvm_dev/llvm_trunk/include -fopt-info -pipe -Wall -Wextra -Ofast -DCLS=64 -fPIC -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wno-error=unused-parameter -Wno-error=type-limits -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++1y -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missi...

Hi, This is regarding support for -fno-delete-null-pointer-checks in clang (PR 9251). Linux kernel uses this flag to keep null pointer checks from getting optimized away. Since clang does not currently support this flag, it often invites comments from kernel devs that clang is not yet *ready* to compile Linux kernel. I have also heard that developers working on firmware, bare-metal tools and

On 2009-09-06 20:52, Bill Wendling wrote: > The problem he's facing here isn't necessarily one of correctness. > He's dealing with undefined behavior (at least in C code). There are > no guarantees that the compiler will retain a certain semantic > interpretation of an undefined construct between different versions of > the compiler, let alone different