Missing documentation regarding initialization with {} in C?
There was recently a discussion with confusion regarding initialization
with {} instead of {0} when initializing an empty array or struct. The
former is not valid in C, but GCC permits it anyway even though it's not
explained anywhere in the specs:
char something[20] = {};
Is it missing from the specs or did I just fail to locate it? I checked
all the C extension pages but none of them had it.
Re: Missing documentation regarding initialization with {} in C?
On Mon, 8 Jul 2019 at 11:33, wrote:
>
> There was recently a discussion with confusion regarding initialization
> with {} instead of {0} when initializing an empty array or struct. The
> former is not valid in C, but GCC permits it anyway even though it's not
> explained anywhere in the specs:
> char something[20] = {};
There is a warning with -Wpedantic:
init.c:1:22: warning: ISO C forbids empty initializer braces [-Wpedantic]
char something[20] = {};
^
> Is it missing from the specs or did I just fail to locate it? I checked
> all the C extension pages but none of them had it.
I think allowing {} is a necessary extension as a consequence of:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
and
https://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html
Allowing it for non-empty arrays does seem to be undocumented though.
Re: Nested loop vectorisation issue
On Sun, Jul 7, 2019 at 8:40 AM Thomas Womack wrote:
>
> Good morning.
>
> I have some code that looks like
>
> typedef unsigned long long uint64;
> typedef unsigned int uint32;
>
> typedef struct { uint64 x[8]; } __attribute__((aligned(64))) v_t;
>
> inline v_t xor(v_t a, v_t b)
> {
> v_t Q;
> for (int i=0; i<8; i++) Q.x[i] = a.x[i] ^ b.x[i];
> return Q;
> }
>
> void xor_matrix_precomp(v_t* __restrict__ a, v_t* __restrict__ c, v_t*
> __restrict__ d, int n)
> {
> uint32 i,j;
> for (i=0; i {
> v_t vi = a[i];
> v_t acc = c[0*256 + (vi.x[0] & 0xff)];
> for (j=1; j<64; j++)
> {
> uint32 w = j>>3, b=j&7;
> acc = xor(acc, c[j*256 + ((vi.x[w] >> (8*b))&0xff)]);
> }
> d[i] = xor(d[i], acc);
> }
> }
>
> built with
>
> /home/nfsworld/tooling/gcc-9.1-isl16/bin/gcc -O3 -fomit-frame-pointer
> -march=skylake-avx512 -mprefer-vector-width=512 -S badeg.c
>
>
> and the inner xor_matrix loop is not vectorised at all: it carries ‘acc’ in
> eight x86-64 registers rather than one ZMM. What am I missing?
>
> -fopt-info-all-vec is not helping me, it points out that it can’t vectorise
> the i or j loop but says nothing about the loop in the inlined xor() call.
The loops are fully unrolled, the vectorizer doesn't see them anymore.
Note the vectorizer is confused about the aggregate copy:
v_t vi = a[i];
which isn't elided.
If you disable the premature unrolling of the xor() look via
-fdisable-tree-cunrolli you get these loops vectorized:
> gcc t.c -O3 -march=skylake-avx512 -mprefer-vector-width=512 -S -fopt-info-vec
> -fdisable-tree-cunrolli
cc1: note: disable pass tree-cunrolli for functions in the range of
[0, 4294967295]
t.c:9:3: optimized: loop vectorized using 64 byte vectors
t.c:9:3: optimized: loop vectorized using 64 byte vectors
(heuristics are difficult...).
Richard.
> I’m sure I’m missing something obvious; many thanks for your help.
>
> Tom
Re: [PATCH] Deprecate -frepo option.
On 6/21/19 4:28 PM, Richard Biener wrote: > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote: >> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote: >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote: On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote: > On 6/21/19 1:47 PM, Jonathan Wakely wrote: >> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote: >>> Yes, I would be fine to deprecate that for GCC 10.1 >> >> Would it be appropriate to issue a warning in GCC 10.x if the option is >> used? > > Sure. With the patch attached one will see: > > $ gcc -frepo /tmp/main.cc -c > gcc: warning: switch ‘-frepo’ is no longer supported > > I'm sending patch that also removes -frepo tests from test-suite. > I've been testing the patch. IMHO for just deprecation of an option you don't want to remove it from the testsuite, just match the warning it will generate in those tests, and I'm not convinced you want to remove it from the documentation (rather than just saying in the documentation that the option is deprecated and might be removed in a later GCC version). >>> >>> Agree with you. I'm sending updated version of the patch. >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> I'm also not convinced about the Deprecated flag, seems like that is a flag >> that we use for options that have been already removed. >> So, instead there should be some proper warning in the C++ FE for it, >> or just Warn. > > In principle -frepo is a nice idea - does it live up to its promises? That > is, > does it actually work, for example when throwing it on the libstdc++ > testsuite or a larger C++ project? I've just tested tramp3d, and it does not survive linking: g++ tramp3d-v4.o collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking collect: recompiling tramp3d-v4.cpp collect: relinking /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `RefCountedBlockPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > >, false, RefBlockController, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > >::RefCountedBlockPtr(RefCountedBlockPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > >, false, RefBlockController, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > > const&)': :(.text+0x4181b): undefined reference to `RefCountedPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > >::RefCountedPtr(RefCountedPtr, ViewEngine<3, IndexFunction >::PositionsFunctor> > > > > const&)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::_Vector_impl::~_Vector_impl()': :(.text+0xc1890): undefined reference to `std::allocator, Interval<3> > >::~allocator()' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::_Vector_base()': :(.text+0xc18aa): undefined reference to `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::_Vector_impl::_Vector_impl()' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::vector, std::allocator > >::_S_use_relocate()': :(.text+0xc496f): undefined reference to `std::vector, std::allocator > >::_S_nothrow_relocate(std::integral_constant)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::~_Vector_base()': :(.text+0xc4cc1): undefined reference to `std::_Vector_base, Interval<3> >, std::allocator, Interval<3> > > >::_M_deallocate(Node, Interval<3> >*, unsigned long)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `DataBlockPtr::DataBlockPtr()': :(.text+0xc6f96): undefined reference to `RefCountedBlockPtr >::RefCountedBlo
Hi everyone, this is unidef
Is it possible to have c or c++ natively have multi dimensional arrays? Instead of using some bourgeois macro function? Sent from my iPhone
Re: Hi everyone, this is unidef
On Mon, 8 Jul 2019 at 14:53, Unidef wrote: > > Is it possible to have c or c++ natively have multi dimensional arrays? > Instead of using some bourgeois macro function? This doesn't seem like a question about GCC development, so is off-topic on this mailing list. If you want to know if it's possible with GCC, then you should use the gcc-help list. If you want to know if it's possible in C or C++ generally, then you should use some other forum dedicated to C and/or C++. They do support multidimensional arrays already, but I assume you mean so you can access them like arr[1,2,3] rather than arr[1][2][3]. The language grammar doesn't currently allow that, because or the meaning of the comma operator, but it might be possible one day in C++, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1161r2.html for a proposed step in that direction. Please take replies to a more appropriate forum.
Re: Hi everyone, this is unidef
I’m really sorry, I have a medical condition heh
But I meant multidimensional functions
I think I can do it with pointer function arrays, but let’s say I have a multi
dimensional multi directional binary tree (graph) and I set it to a _all struct
I want to do
secure _all[200][macro] /* etc */ sort(_all Data[etc][])[]{
// all ai functions
return data_index[],,;
}
I just want the c part to do this, I don’t have time to rewrite the entire
collection. How would I implement it in gcc? I don’t really like clang but it’s
nice
Sent from my iPhone
> On Jul 8, 2019, at 8:29 AM, Jonathan Wakely wrote:
>
>> On Mon, 8 Jul 2019 at 14:53, Unidef wrote:
>>
>> Is it possible to have c or c++ natively have multi dimensional arrays?
>> Instead of using some bourgeois macro function?
>
> This doesn't seem like a question about GCC development, so is
> off-topic on this mailing list.
>
> If you want to know if it's possible with GCC, then you should use the
> gcc-help list. If you want to know if it's possible in C or C++
> generally, then you should use some other forum dedicated to C and/or
> C++.
>
> They do support multidimensional arrays already, but I assume you mean
> so you can access them like arr[1,2,3] rather than arr[1][2][3]. The
> language grammar doesn't currently allow that, because or the meaning
> of the comma operator, but it might be possible one day in C++, see
> https://u8262.ct.sendgrid.net/wf/click?upn=wFa61dLReLL4rLypSmB8qNiwmx6M7DX1N29CRD9e-2BvsOJ3EnQ2tzbe4PrNQ25DomlJRZsTmDU-2BophHKdGmZfOxiXgvaty-2FROjtxLepXEKX4-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CVXYiZDaHzVYs5h25jOaNipnFszYaf-2BPfewQQ1dSIjNwwsyLZdHrE0QHtxerVOljmNbrKQrfbsRY-2FU0ZrG5KoIOdZx-2FKERPoGNJku2W6K4sCDEk2ch6En3Xa2LYT6ckmHT1vGqP3Tdz6qgyoDw2NP9HjxTAgecLxhDcu-2F-2Fim0NHfw-3D-3D
> for a proposed step in that direction.
>
> Please take replies to a more appropriate forum.
Re: Hi everyone, this is unidef
On Mon, 8 Jul 2019 at 21:44, Unidef wrote: > I’m really sorry, I have a medical condition heh > > But I meant multidimensional functions > This is still the wrong mailing list though.
Re: Hi everyone, this is unidef
Please take your personal political agenda to private email. This is a mailing list, not your soap box. Saying that I’m unsubscribing and using Linux or geonode as my ai platform. Sent from my iPhone > On Jul 8, 2019, at 2:53 PM, Jonathan Wakely wrote: > > > >> On Mon, 8 Jul 2019 at 21:44, Unidef wrote: >> I’m really sorry, I have a medical condition heh >> >> But I meant multidimensional functions >> > > This is still the wrong mailing list though. > >
