Re: Enable -Wreturn-type by default ?
On 17/11/2013 06:03, Alec Teal wrote:
> Who isn't compiling with -Wall and -Wextra?
>
Plenty of users ...
> I do hope Clang ('though I don't use it) doesn't make it an error
> because not all functions have to return in C iirc.
It does.
It makes 120 packages fail to build from source in Debian (on 18854
packages):
http://clang.debian.net/status.php?version=3.3&key=FUNCTION_RETURNS_VALUE
Sylvestre
Re: Vectorization: Loop peeling with misaligned support.
On 11/16/2013 04:25 AM, Tim Prince wrote: Many decisions on compiler defaults still are based on an unscientific choice of benchmarks, with gcc evidently more responsive to input from the community. I'm also quite convinced that we are hampered by the fact that there is no IPA on alignment in GCC. I bet that in the average Fortran program, most arrays are suitably aligned (after all, they're either a - by definition - SAVEd array in a module, or an ALLOCATEd array), and code that does this: CALL AAP(..., A(2), ...) is relatively sparse. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Enable -Wreturn-type by default ?
On Sun, 17 Nov 2013, Sylvestre Ledru wrote:
On 17/11/2013 06:03, Alec Teal wrote:
I do hope Clang ('though I don't use it) doesn't make it an error
because not all functions have to return in C iirc.
It does.
It makes 120 packages fail to build from source in Debian (on 18854
packages):
http://clang.debian.net/status.php?version=3.3&key=FUNCTION_RETURNS_VALUE
That's cool, if clang forces people to update their code to C99, maybe
we'll be able to switch gcc to use -std=gnu99 by default one day...
--
Marc Glisse
Re: OpenACC in GCC - how does it not violate the license?
> On Nov 16, 2013, at 11:22 PM, Jeff Law wrote: > >> On 11/16/13 21:58, Alec Teal wrote: >> Now while great, is this true!? Nvidia (IIRC, this was like a year ago >> though) don't even give out the instruction set for their GPUs, can we >> have GCC targeting closed things? Also there (must be and is) a Cuda >> runtime, wouldn't we need an open runtime to link against? > The various projects looking at supporting OpenACC are, to the best of my > knowledge, targeting PTX, which is a virtual ISA from NVidia which is > published. > > Going from PTX to the actual instructions for the particular GPU is the job > of a runtime system which would be provided by NVidia. > If one wants to tilt at these windmills, we should belabor the lack of open documentation of the microcode corresponding to the x86 instruction set. Jeff > However, there's no reason why OpenACC couldn't target the host CPU or > another GPU. In fact, that's what I'd initially do if I were working on this. > >> >> This is by no means an accusation, I'm sure he's doing fine work; but >> he's doing something I didn't think the GPLv3 allowed (so I want to be >> corrected) he seems to have added something that requires a closed >> runtime for a target with a closed instruction set - probably for Nvidia >> (as he is responsible for "strategic partnerships" with them) > To answer that question you'd need to talk to your lawyer. > > jeff
Re: OpenACC in GCC - how does it not violate the license?
On 11/17/13 07:32, Jeff Hammond wrote: On Nov 16, 2013, at 11:22 PM, Jeff Law wrote: On 11/16/13 21:58, Alec Teal wrote: Now while great, is this true!? Nvidia (IIRC, this was like a year ago though) don't even give out the instruction set for their GPUs, can we have GCC targeting closed things? Also there (must be and is) a Cuda runtime, wouldn't we need an open runtime to link against? The various projects looking at supporting OpenACC are, to the best of my knowledge, targeting PTX, which is a virtual ISA from NVidia which is published. Going from PTX to the actual instructions for the particular GPU is the job of a runtime system which would be provided by NVidia. If one wants to tilt at these windmills, we should belabor the lack of open documentation of the microcode corresponding to the x86 instruction set. I certainly have in the context of PTX, HSA and Intel's integrated GPU support for GCC. Intel and AMD appear to me to be ahead of the curve here -- both in documentation and in terms of minimizing the size of the black box binary blob necessary to make this stuff work. But in the end, my influence is limited for a variety of reasons. Regardless, I continue to raise these issues with the appropriate folks when the opportunities present themselves. jeff
Re: Enable -Wreturn-type by default ?
On Sun, 17 Nov 2013, Marc Glisse wrote:
> On Sun, 17 Nov 2013, Sylvestre Ledru wrote:
>
> > On 17/11/2013 06:03, Alec Teal wrote:
> > > I do hope Clang ('though I don't use it) doesn't make it an error
> > > because not all functions have to return in C iirc.
> > It does.
> > It makes 120 packages fail to build from source in Debian (on 18854
> > packages):
> > http://clang.debian.net/status.php?version=3.3&key=FUNCTION_RETURNS_VALUE
>
> That's cool, if clang forces people to update their code to C99, maybe we'll
> be able to switch gcc to use -std=gnu99 by default one day...
Any GCC release always requires some third-party code that was doing
dubious things to be updated to work with changes in GCC - the extent of
such code may be indicative of whether a change can be made to GCC (and
how hard it is to fix the third-party code may help indicate whether GCC
needs to be more relaxed in a particular case, e.g. making something a
pedwarn-if-pedantic rather than a hard error) but doesn't determine it.
I think people quite commonly use -pedantic with GCC in its default
(-std=gnu89) mode to get warnings about C99 features creeping into their
code if they want to keep it compilable without needing a C99 compiler.
With a default of -std=gnu99, -pedantic would no longer give those
warnings and they'd need to make the previous default -std=gnu89 explicit
to get them. I think we should provide a better solution for such users
to get those warnings without changing the selected language versions -
that is, options to warn about C90/C99 and C99/C11 compatibility issues in
the cases where we presently give pedwarns (occasionally warnings, in
particular for format checking) if pedantic and in C90/C99 mode. (The
diagnostics would be pedwarns or warnings as appropriate for the language
version. See pedwarn_c90.) Bug 51849.
Given such -Wc90-c99-compat and -Wc99-c11-compat options, I think we could
move the default straight to -std=gnu11, C11 support now being
substantially on par with C99 support. (I still need to update
implement-c.texi for C11 and some other bits of documentation for the
state of C99 and C11 support, but that doesn't need to be done in
development stage 1. And release notes are still needed for for _Generic,
_Atomic and _Thread_local support.)
--
Joseph S. Myers
jos...@codesourcery.com
Re: Enable -Wreturn-type by default ?
On 14/11/2013 12:48, Jonathan Wakely wrote:
> On 14 November 2013 11:31, Dodji Seketeli wrote:
>> For C, I am not sure about, but I'd find it useful to have that warning
>> enabled there too, so I guess I'd like to hear why the warning wasn't
>> enabled there by default there as well.
> A return statement with no operand is always wrong, but -Wreturn-type
> also warns about this, which is valid:
>
> int f(int c)
> {
> if (c)
>return 0;
> function_that_never_returns();
> }
>
> The noreturn attribute is not portable, and can't necessarily be added
> to library functions not controlled by the user.
>
> So maybe it makes sense to split -Wreturn-type to separately handle
> "return with no value in function returning non-void" and "control
> reaches end of non-void function".
I wrote a patch for this. I am updating the tests (many of them have now
warnings because of -Wreturn-type).
I updated 410 of them and I am still doing the work. Hopefully, I will
send a patch in the next few days...
For "control reaches end of non-void function", I haven't activated by
default and I called the option -Wfalloff-nonvoid-function
Of course, that is just a proposal! :) Better names are welcome.
Sylvestre
Re: Vectorization: Loop peeling with misaligned support.
"Ondřej Bílka" wrote:
>On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote:
>> "Ondřej Bílka" wrote:
>> >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
>>
>> IIRC what can still be seen is store-buffer related slowdowns when
>you have a big unaligned store load in your loop. Thus aligning stores
>still pays back last time I measured this.
>
>Then send you benchmark. What I did is a loop that stores 512 bytes.
>Unaligned stores there are faster than aligned ones, so tell me when
>aligning stores pays itself. Note that in filling store buffer you must
>take into account extra stores to make loop aligned.
The issue is that the effective write bandwidth can be limited by the store
buffer if you have multiple write streams. IIRC at least some amd CPUs have to
use two entries for stores crossing a cache line boundary.
Anyway, a look into the optimization manuals will tell you what to do and the
cost model should follow these recommendations.
>Also what do you do with loops that contain no store? If I modify test
>to
>
>int set(int *p, int *q){
> int i;
> int sum = 0;
> for (i=0; i < 128; i++)
> sum += 42 * p[i];
> return sum;
>}
>
>then it still does aligning.
Because the cost model simply does not exist for the decision whether to peel
or not. Patches welcome.
>There may be a threshold after which aligning buffer makes sense then
>you
>need to show that loop spend most of time on sizes after that treshold.
>
>Also do you have data how common store-buffer slowdowns are? Without
>knowing that you risk that you make few loops faster at expense of
>majority which could likely slow whole application down. It would not
>supprise me as these loops can be ran mostly on L1 cache data (which is
>around same level as assuming that increased code size fits into
>instruction cache.)
>
>
>Actually these questions could be answered by a test, first compile
>SPEC2006 with vanilla gcc -O3 and then with gcc that contains patch to
>use unaligned loads. Then results will tell if peeling is also good in
>practice or not.
It should not be a on or off decision but rather a decision based on a cost
model.
Richard.
Re: Enable -Wreturn-type by default ?
On 17 November 2013 15:40, Sylvestre Ledru wrote: > For "control reaches end of non-void function", I haven't activated by > default and I called the option -Wfalloff-nonvoid-function > Of course, that is just a proposal! :) Better names are welcome. It was nearly called -Wmissing-return a decade ago, but got bundled with -Wreturn-type, see http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02002.html
PATCH: Add R_X86_64_PC32_BND and R_X86_64_PLT32_BND
Hi,
This binutils adds R_X86_64_PC32_BND and R_X86_64_PLT32_BND as specified
in
https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/Cmukf_krWl4
These 2 relocations only appear in relocatable files. They have no
impact on glibc nor gcc. I am checking it into master and 2.24 branch.
Thanks.
H.J.
---
bfd/
* elf64-x86-64.c (x86_64_elf_howto_table): Add R_X86_64_PC32_BND
and R_X86_64_PLT32_BND.
(R_X86_64_standard): Replace R_X86_64_RELATIVE64 with
R_X86_64_PLT32_BND.
(IS_X86_64_PCREL_TYPE): Add R_X86_64_PLT32_BND.
(x86_64_reloc_map): Add BFD_RELOC_X86_64_PC32_BND and
BFD_RELOC_X86_64_PLT32_BND.
(elf_x86_64_check_relocs): Handle R_X86_64_PC32_BND and
R_X86_64_PLT32_BND.
(elf_x86_64_gc_sweep_hook): Likewise.
(elf_x86_64_relocate_section): Likewise.
* reloc.c (bfd_reloc_code_real): Add BFD_RELOC_X86_64_PC32_BND
and BFD_RELOC_X86_64_PLT32_BND.
* bfd-in2.h: Regenerated.
* libbfd.h: Likewise.
gas/
* config/tc-i386.c (reloc): Add an argument, bnd_prefix, to
indicate if instruction has the BND prefix. Return
BFD_RELOC_X86_64_PC32_BND instead of BFD_RELOC_32_PCREL if
bnd_prefix isn't zero.
(output_branch): Pass BFD_RELOC_X86_64_PC32_BND to frag_var
if needed.
(output_jump): Update reloc call.
(output_interseg_jump): Likewise.
(output_disp): Likewise.
(output_imm): Likewise.
(x86_cons_fix_new): Likewise.
(lex_got): Add an argument, bnd_prefix, to indicate if
instruction has the BND prefix. Use BFD_RELOC_X86_64_PLT32_BND
if needed.
(x86_cons): Update lex_got call.
(i386_immediate): Likewise.
(i386_displacement): Likewise.
(md_apply_fix): Handle BFD_RELOC_X86_64_PC32_BND and
BFD_RELOC_X86_64_PLT32_BND.
(tc_gen_reloc): Likewise.
* config/tc-i386-intel.c (i386_operator): Update lex_got call.
gas/testsuite/
* gas/i386/i386.exp: Run x86-64-mpx-branch-1 and
x86-64-mpx-branch-2 on 64-bit ELF targets.
* gas/i386/x86-64-mpx-branch-1.d: New file.
* gas/i386/x86-64-mpx-branch-1.s: Likewise.
* gas/i386/x86-64-mpx-branch-2.d: Likewise.
* gas/i386/x86-64-mpx-branch-2.s: Likewise.
include/elf/
* x86-64.h: Add R_X86_64_PC32_BND and R_X86_64_PLT32_BND.
ld/testsuite/
* ld-x86-64/mpx.exp: New file.
* ld-x86-64/mpx1.out: Likewise.
* ld-x86-64/mpx1a.c: Likewise.
* ld-x86-64/mpx1a.rd: Likewise.
* ld-x86-64/mpx1b.c: Likewise.
* ld-x86-64/mpx1c.c: Likewise.
* ld-x86-64/mpx1c.rd: Likewise.
diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index 79f2130..846116b 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -3125,6 +3125,8 @@ instruction. */
BFD_RELOC_X86_64_TLSDESC_CALL,
BFD_RELOC_X86_64_TLSDESC,
BFD_RELOC_X86_64_IRELATIVE,
+ BFD_RELOC_X86_64_PC32_BND,
+ BFD_RELOC_X86_64_PLT32_BND,
/* ns32k relocations */
BFD_RELOC_NS32K_IMM_8,
diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 6ff5f36..8eac635 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -172,12 +172,18 @@ static reloc_howto_type x86_64_elf_howto_table[] =
HOWTO(R_X86_64_RELATIVE64, 0, 4, 64, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_X86_64_RELATIVE64", FALSE, MINUS_ONE,
MINUS_ONE, FALSE),
+ HOWTO(R_X86_64_PC32_BND, 0, 2, 32, TRUE, 0, complain_overflow_signed,
+ bfd_elf_generic_reloc, "R_X86_64_PC32_BND", FALSE, 0x,
0x,
+ TRUE),
+ HOWTO(R_X86_64_PLT32_BND, 0, 2, 32, TRUE, 0, complain_overflow_signed,
+ bfd_elf_generic_reloc, "R_X86_64_PLT32_BND", FALSE, 0x,
0x,
+ TRUE),
/* We have a gap in the reloc numbers here.
R_X86_64_standard counts the number up to this point, and
R_X86_64_vt_offset is the value to subtract from a reloc type of
R_X86_64_GNU_VT* to form an index into this table. */
-#define R_X86_64_standard (R_X86_64_RELATIVE64 + 1)
+#define R_X86_64_standard (R_X86_64_PLT32_BND + 1)
#define R_X86_64_vt_offset (R_X86_64_GNU_VTINHERIT - R_X86_64_standard)
/* GNU extension to record C++ vtable hierarchy. */
@@ -199,6 +205,7 @@ static reloc_howto_type x86_64_elf_howto_table[] =
( ((TYPE) == R_X86_64_PC8) \
|| ((TYPE) == R_X86_64_PC16)\
|| ((TYPE) == R_X86_64_PC32)\
+ || ((TYPE) == R_X86_64_PC32_BND)\
|| ((TYPE) == R_X86_64_PC64))
/* Map BFD relocs to the x86_64 elf relocs. */
@@ -248,6 +255,8 @@ static const struct elf_reloc_map x86_64_reloc_map[] =
{ BFD_RELOC_X86_64_TLSDESC_CALL, R_X86_64_TLSDESC_CALL, },
{ BFD_RELOC_X86_64_TLSDESC, R_X86_64_TLSDESC, },
{ BFD_RELOC_X86_64_IRELATIVE,R_X86_64_IRELATIVE, },
+ { BFD_RELOC_X86_64_PC32_BND, R_X86_64_PC32_BND,},
+ { BFD_RELOC_X86_64_PLT32_BND,R_X86_64_PLT32_BND,},
{ BFD
Re: Vectorization: Loop peeling with misaligned support.
On Sun, Nov 17, 2013 at 04:42:18PM +0100, Richard Biener wrote:
> "Ondřej Bílka" wrote:
> >On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote:
> >> "Ondřej Bílka" wrote:
> >> >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
> >>
> >> IIRC what can still be seen is store-buffer related slowdowns when
> >you have a big unaligned store load in your loop. Thus aligning stores
> >still pays back last time I measured this.
> >
> >Then send you benchmark. What I did is a loop that stores 512 bytes.
> >Unaligned stores there are faster than aligned ones, so tell me when
> >aligning stores pays itself. Note that in filling store buffer you must
> >take into account extra stores to make loop aligned.
>
> The issue is that the effective write bandwidth can be limited by the store
> buffer if you have multiple write streams. IIRC at least some amd CPUs have
> to use two entries for stores crossing a cache line boundary.
>
So can be performance limited by branch misprediction. You need to show
that likely bottleneck is too much writes and not other factor.
> Anyway, a look into the optimization manuals will tell you what to do and the
> cost model should follow these recommendations.
>
These tend to be quite out of data, you typically need to recheck
everything.
Take
Intel® 64 and IA-32 Architectures Optimization Reference Manual
from April 2012
A sugestion on store load forwarding there is to align loads and stores
to make it working (with P4 and core2 suggestions).
However this is false since nehalem, when I test a variant of memcpy
that is unaligned by one byte, code is following (full benchmark attached.):
set:
.LFB0:
.cfi_startproc
xor %rdx, %rdx
addq$1, %rsi
lea 144(%rsi), %rdi
.L:
movdqu 0(%rsi,%rdx), %xmm0
movdqu 16(%rsi,%rdx), %xmm1
...
movdqu 112(%rsi,%rdx), %xmm7
movdqu %xmm0, 0(%rdi,%rdx)
...
movdqu %xmm7, 112(%rdi,%rdx)
addq$128, %rdx
cmp $5120, %rdx
jle .L
ret
Then there is around 10% slowdown vs nonforwarding one.
real0m2.098s
user0m2.083s
sys 0m0.003s
However when I set 'in lea 144(%rsi), %rdi' a 143 or other nonmultiple of 16
then
performance degrades.
real0m3.495s
user0m3.480s
sys 0m0.000s
And other suggestions are similarly flimsy unless your target is pentium 4.
> >Also what do you do with loops that contain no store? If I modify test
> >to
> >
> >int set(int *p, int *q){
> > int i;
> > int sum = 0;
> > for (i=0; i < 128; i++)
> > sum += 42 * p[i];
> > return sum;
> >}
> >
> >then it still does aligning.
>
> Because the cost model simply does not exist for the decision whether to peel
> or not. Patches welcome.
>
> >There may be a threshold after which aligning buffer makes sense then
> >you
> >need to show that loop spend most of time on sizes after that treshold.
> >
> >Also do you have data how common store-buffer slowdowns are? Without
> >knowing that you risk that you make few loops faster at expense of
> >majority which could likely slow whole application down. It would not
> >supprise me as these loops can be ran mostly on L1 cache data (which is
> >around same level as assuming that increased code size fits into
> >instruction cache.)
> >
> >
> >Actually these questions could be answered by a test, first compile
> >SPEC2006 with vanilla gcc -O3 and then with gcc that contains patch to
> >use unaligned loads. Then results will tell if peeling is also good in
> >practice or not.
>
> It should not be a on or off decision but rather a decision based on a cost
> model.
>
You cannot decide that on cost model alone as performance is decided by
runtime usage pattern. If you do profiling then you could do that.
Alternatively you can add a branch to enable peeling only after preset
treshold.
#define _GNU_SOURCE
#include
#include
int main(){
char *ptr = pvalloc(2 * SIZE + 1);
char *ptr2 = pvalloc(2 * SIZE + 1);
unsigned long p = 31;
unsigned long q = 17;
int i;
for (i=0; i < 800; i++) {
set (ptr + 64 * (p % (SIZE / 64)), ptr2 + 64 * (q % (SIZE /64)));
p = 11 * p + 3;
q = 13 * p + 5;
}
}
.file "set1.c"
.text
.p2align 4,,15
.globl set
.type set, @function
set:
.LFB0:
.cfi_startproc
xor %rdx, %rdx
addq$1, %rsi
lea 144(%rsi), %rdi
.L:
movdqu 0(%rsi,%rdx), %xmm0
movdqu 16(%rsi,%rdx), %xmm1
movdqu 32(%rsi,%rdx), %xmm2
movdqu 48(%rsi,%rdx), %xmm3
movdqu 64(%rsi,%rdx), %xmm4
movdqu 80(%rsi,%rdx), %xmm5
movdqu 96(%rsi,%rdx), %xmm6
movdqu 112(%rsi,%rdx), %xmm7
movdqu %xmm0, 0(%rdi,%rdx)
movdqu %xmm1, 16(%rdi,%rdx)
movdqu %xmm2, 32(%rdi,%rdx)
movdqu %xmm3, 48(%rdi,%rdx)
movdqu %xmm4, 64(%rdi,%rdx)
movdq
memset zero bytes at NULL - isolate-erroneous-paths
In the following code (from xorg-server) if (a == 0) addr = 0; (...) memset(addr, '\0', a); the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is calling memset like this undefined behaviour?) Is it intentional that essentially a noop is turned into a trap? Dominic
Re: memset zero bytes at NULL - isolate-erroneous-paths
On 17 November 2013 18:25, Dominic News wrote: > In the following code (from xorg-server) > > if (a == 0) > addr = 0; > (...) > memset(addr, '\0', a); > > the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is > calling memset like this undefined behaviour?) Yes. 7.23.1 in the C standard says that even with a zero size the pointer argument must be valid.
PLUGIN_HEADER_FILE event for tracing of header inclusions.
Hello All,
I strongly believe that plugins should be able to be notified of
included headers. Notice that end-users already can be notified with the
-H option of gcc.
This is useful e.g. for plugins which are interfacing to some IDE (like
Eclispe, Geany, ...), because the editor really wants to know when a
header file is used.
MELT [see gcc-melt.org] certainly will be very happy if a
PLUGIN_HEADER_FILE event existed for that purpose. It would make its
probe (or the future "monitor" of MELT) much simpler, because every
included file would easily be passed to the MELT plugin and to the
probe. (Currently MELT deals with that by constructing a set of files
for the locations, but that is painful).
In principle the patch should be quite simple; add in function
linemap_add of libcpp/line-map.c, near line 380, for reason == LC_ENTER
just before testing set->trace_includes, some lines like
/* Signal to plugins that a header file is included. */
invoke_plugin_callbacks (PLUGIN_HEADER_FILE,
ORDINARY_MAP_FILE_NAME (map));
but that requires a #include "plugin.h" in that file libcpp/line-map.c,
and then GCC machinery (autodependencies for make, etc...) is unhappy
(because this requires -I$(srcdir)/../gcc to be added in the Makefile.in
of libcpp/)
What would be the good way to add such a plugin event to GCC 4.9?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: OpenACC in GCC - how does it not violate the license?
On 11/16/13 22:22, Jeff Law wrote: On 11/16/13 21:58, Alec Teal wrote: Now while great, is this true!? Nvidia (IIRC, this was like a year ago though) don't even give out the instruction set for their GPUs, can we have GCC targeting closed things? Also there (must be and is) a Cuda runtime, wouldn't we need an open runtime to link against? The various projects looking at supporting OpenACC are, to the best of my knowledge, targeting PTX, which is a virtual ISA from NVidia which is published. Correct. PTX is a perfectly well defined architecture, albeit for a virtual machine. The specification is public. IMHO this is no different to, say, targeting Java byte code.
Re: memset zero bytes at NULL - isolate-erroneous-paths
* Jonathan Wakely: > On 17 November 2013 18:25, Dominic News wrote: >> In the following code (from xorg-server) >> >> if (a == 0) >> addr = 0; >> (...) >> memset(addr, '\0', a); >> >> the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is >> calling memset like this undefined behaviour?) > > Yes. 7.23.1 in the C standard says that even with a zero size the > pointer argument must be valid. Is this new in C11? Does it apply to functions such as strnlen as well?
Re: memset zero bytes at NULL - isolate-erroneous-paths
On Sun, 17 Nov 2013, Florian Weimer wrote: * Jonathan Wakely: On 17 November 2013 18:25, Dominic News wrote: In the following code (from xorg-server) if (a == 0) addr = 0; (...) memset(addr, '\0', a); the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is calling memset like this undefined behaviour?) Yes. 7.23.1 in the C standard says that even with a zero size the pointer argument must be valid. Is this new in C11? Does it apply to functions such as strnlen as well? It was already in C99 (I don't have anything older at hand), a paragraph at the beginning of the description of string.h. It does not apply to strnlen_s. For strnlen, which is only in posix, I am not sure, but glibc has the nonnull attribute. -- Marc Glisse
Re: memset zero bytes at NULL - isolate-erroneous-paths
On 11/17/13 15:02, Florian Weimer wrote: * Jonathan Wakely: On 17 November 2013 18:25, Dominic News wrote: In the following code (from xorg-server) if (a == 0) addr = 0; (...) memset(addr, '\0', a); the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is calling memset like this undefined behaviour?) Yes. 7.23.1 in the C standard says that even with a zero size the pointer argument must be valid. Is this new in C11? Does it apply to functions such as strnlen as well? No, it's C99 I think. There was a clarification which came in after C99 which clarified that even if the length is zero, the pointers must still be valid. The language is such that unless there's an explicit exception for a particular function, those rules always apply. jeff
Re: memset zero bytes at NULL - isolate-erroneous-paths
* Jeff Law: >> Is this new in C11? Does it apply to functions such as strnlen as well? > No, it's C99 I think. There was a clarification which came in after > C99 which clarified that even if the length is zero, the pointers must > still be valid. Okay, I found the language in sections 7.1.4 and 7.21.1 (thanks Marc). This is a bit unfortunate because it interoperates poorly with std::vector::data(), which can return a null pointer if the vector is empty.
